From: Wesley Cheng <quic_wcheng@quicinc.com> To: Takashi Iwai <tiwai@suse.de>, Oliver Neukum <oneukum@suse.com> Cc: <srinivas.kandagatla@linaro.org>, <mathias.nyman@intel.com>, <perex@perex.cz>, <broonie@kernel.org>, <lgirdwood@gmail.com>, <andersson@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <gregkh@linuxfoundation.org>, <Thinh.Nguyen@synopsys.com>, <bgoswami@quicinc.com>, <tiwai@suse.com>, <robh+dt@kernel.org>, <agross@kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <alsa-devel@alsa-project.org>, <devicetree@vger.kernel.org>, <linux-usb@vger.kernel.org>, <quic_jackp@quicinc.com>, <quic_plai@quicinc.com> Subject: Re: [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op callbacks Date: Tue, 3 Jan 2023 15:45:27 -0800 [thread overview] Message-ID: <54f36fe7-c590-3d5c-58dc-c5a02c412487@quicinc.com> (raw) In-Reply-To: <87v8lnrde2.wl-tiwai@suse.de> Hi Oliver, On 1/3/2023 4:49 AM, Takashi Iwai wrote: > On Tue, 03 Jan 2023 13:20:48 +0100, > Oliver Neukum wrote: >> >> >> >> On 30.12.22 08:10, Wesley Cheng wrote: >> >>> It may depend on how the offloading is implemented, but we do have a mechanism to force the audio stream off from the qc_usb_audio_offload. Regardless of if the UDEV is suspended first, or the USB backend, as long as we ensure that the offloading is disabled before entering suspend, I think that should be sufficient. >> >> You would presumably output garbage, if the UDEV is asleep but the backend is not. >> As long as the stream is halted, i.e. the audio DSP doesn't execute further transfers on the bus, there shouldn't be any noise/static that will continue to be outputted. When I mentioned that we have a mechanism to force for the offloading to be disabled to the audio DSP side, it will no longer submit any audio data to the USB bus. >> >>> The reset_resume() path is fine. Bus reset is going to cause a disconnect() callback in the offload driver, in which we already have the proper handling for ensuring the offload path is halted, and we reject any incoming stream start requests. >> >> How? If we go the reset_resume() code path, we find that usb-audio does not make >> a difference between regular resume() and reset_resume() > > Note that, for USB audio, there is no much difference between resume() > and reset_resume(), especially about the PCM stream handling that is > the main target for the offload (the mixer isn't handled there). > And for the PCM, we just set the power state for UAC3, and that's > all. All the rest is handled by the PCM core handler as usual. > Sorry, I was under the impression that the USB SND class driver didn't register a reset_resume() callback, which Takashi helped clarify that it does indeed do. (if no callback is registered, then USB interface is re-binded in the resume path) However, it doesn't explicitly treat the reset_resume differently than a normal resume. For the offload path, we don't need to do anything special either - if we have ensured that the stream was stopped in the suspend path. (to be added) It would be up to the userspace to restart the ASoC PCM stream, which would cause another stream request enable QMI command handshake to happen before any transfers would start. One thing that I could add to protect the situation where the USB ASoC backend is resumed before UDEV, is to check the chip->system_suspend state. Normally, the offload driver needs to ensure the bus is in U0 before starting the audio stream, but it is done using runtime PM: static int enable_audio_stream(struct snd_usb_substream *subs, snd_pcm_format_t pcm_format, unsigned int channels, unsigned int cur_rate, int datainterval) { ... pm_runtime_barrier(&chip->intf[0]->dev); snd_usb_autoresume(chip); In case we're in the PM resume path, I don't believe PM runtime can be triggered to resume a device. In this case, the snd_usb_autoresume() would return w/o ensuring the USB SND device is fully exited from PM suspend. Although, this situation would be a corner case, as userspace entities (userspace ALSA) are going to be unfrozen after kernel devices are resumed, so most likely there should be no request to enable the audio stream if kernel devices are still resuming. I don't see an issue with the sequence of UDEV being resumed before USB backend. In this case, the USB bus is ready to go, and able to handle stream enable requests. Thanks Wesley Cheng
WARNING: multiple messages have this Message-ID (diff)
From: Wesley Cheng <quic_wcheng@quicinc.com> To: Takashi Iwai <tiwai@suse.de>, Oliver Neukum <oneukum@suse.com> Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, bgoswami@quicinc.com, mathias.nyman@intel.com, gregkh@linuxfoundation.org, andersson@kernel.org, tiwai@suse.com, lgirdwood@gmail.com, robh+dt@kernel.org, broonie@kernel.org, srinivas.kandagatla@linaro.org, agross@kernel.org, krzysztof.kozlowski+dt@linaro.org, Thinh.Nguyen@synopsys.com, quic_plai@quicinc.com, linux-kernel@vger.kernel.org, quic_jackp@quicinc.com Subject: Re: [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op callbacks Date: Tue, 3 Jan 2023 15:45:27 -0800 [thread overview] Message-ID: <54f36fe7-c590-3d5c-58dc-c5a02c412487@quicinc.com> (raw) In-Reply-To: <87v8lnrde2.wl-tiwai@suse.de> Hi Oliver, On 1/3/2023 4:49 AM, Takashi Iwai wrote: > On Tue, 03 Jan 2023 13:20:48 +0100, > Oliver Neukum wrote: >> >> >> >> On 30.12.22 08:10, Wesley Cheng wrote: >> >>> It may depend on how the offloading is implemented, but we do have a mechanism to force the audio stream off from the qc_usb_audio_offload. Regardless of if the UDEV is suspended first, or the USB backend, as long as we ensure that the offloading is disabled before entering suspend, I think that should be sufficient. >> >> You would presumably output garbage, if the UDEV is asleep but the backend is not. >> As long as the stream is halted, i.e. the audio DSP doesn't execute further transfers on the bus, there shouldn't be any noise/static that will continue to be outputted. When I mentioned that we have a mechanism to force for the offloading to be disabled to the audio DSP side, it will no longer submit any audio data to the USB bus. >> >>> The reset_resume() path is fine. Bus reset is going to cause a disconnect() callback in the offload driver, in which we already have the proper handling for ensuring the offload path is halted, and we reject any incoming stream start requests. >> >> How? If we go the reset_resume() code path, we find that usb-audio does not make >> a difference between regular resume() and reset_resume() > > Note that, for USB audio, there is no much difference between resume() > and reset_resume(), especially about the PCM stream handling that is > the main target for the offload (the mixer isn't handled there). > And for the PCM, we just set the power state for UAC3, and that's > all. All the rest is handled by the PCM core handler as usual. > Sorry, I was under the impression that the USB SND class driver didn't register a reset_resume() callback, which Takashi helped clarify that it does indeed do. (if no callback is registered, then USB interface is re-binded in the resume path) However, it doesn't explicitly treat the reset_resume differently than a normal resume. For the offload path, we don't need to do anything special either - if we have ensured that the stream was stopped in the suspend path. (to be added) It would be up to the userspace to restart the ASoC PCM stream, which would cause another stream request enable QMI command handshake to happen before any transfers would start. One thing that I could add to protect the situation where the USB ASoC backend is resumed before UDEV, is to check the chip->system_suspend state. Normally, the offload driver needs to ensure the bus is in U0 before starting the audio stream, but it is done using runtime PM: static int enable_audio_stream(struct snd_usb_substream *subs, snd_pcm_format_t pcm_format, unsigned int channels, unsigned int cur_rate, int datainterval) { ... pm_runtime_barrier(&chip->intf[0]->dev); snd_usb_autoresume(chip); In case we're in the PM resume path, I don't believe PM runtime can be triggered to resume a device. In this case, the snd_usb_autoresume() would return w/o ensuring the USB SND device is fully exited from PM suspend. Although, this situation would be a corner case, as userspace entities (userspace ALSA) are going to be unfrozen after kernel devices are resumed, so most likely there should be no request to enable the audio stream if kernel devices are still resuming. I don't see an issue with the sequence of UDEV being resumed before USB backend. In this case, the USB bus is ready to go, and able to handle stream enable requests. Thanks Wesley Cheng
next prev parent reply other threads:[~2023-01-03 23:46 UTC|newest] Thread overview: 171+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-23 23:31 [RFC PATCH 00/14] Introduce QC USB SND audio offloading support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 01/14] ASoC: Add SOC USB APIs for adding an USB backend Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 6:48 ` Greg KH 2022-12-24 6:48 ` Greg KH 2022-12-23 23:31 ` [RFC PATCH 02/14] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 1:37 ` kernel test robot 2023-01-04 23:33 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 16:09 ` Pierre-Louis Bossart 2023-01-07 0:51 ` Wesley Cheng 2023-01-07 0:51 ` Wesley Cheng 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-06 1:32 ` Wesley Cheng 2023-01-06 1:32 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 03/14] ASoC: qcom: Add USB backend ASoC driver for Q6 Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:17 ` kernel test robot 2022-12-24 2:17 ` kernel test robot 2022-12-24 9:02 ` Greg KH 2022-12-24 9:02 ` Greg KH 2022-12-27 13:04 ` Mark Brown 2022-12-27 13:04 ` Mark Brown 2022-12-27 13:45 ` Greg KH 2022-12-27 13:45 ` Greg KH 2022-12-27 14:02 ` Takashi Iwai 2022-12-27 14:02 ` Takashi Iwai 2022-12-27 14:11 ` Mark Brown 2022-12-27 14:11 ` Mark Brown 2022-12-27 15:11 ` Mark Brown 2022-12-27 15:11 ` Mark Brown 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2023-01-04 23:41 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 16:16 ` Pierre-Louis Bossart 2022-12-23 23:31 ` [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op callbacks Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 11:03 ` Dmitry Baryshkov 2022-12-24 11:03 ` Dmitry Baryshkov 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:33 ` Dmitry Baryshkov 2022-12-27 21:33 ` Dmitry Baryshkov 2022-12-29 13:49 ` Oliver Neukum 2022-12-29 13:49 ` Oliver Neukum 2022-12-29 14:20 ` Takashi Iwai 2022-12-29 14:20 ` Takashi Iwai 2022-12-30 7:10 ` Wesley Cheng 2022-12-30 7:10 ` Wesley Cheng 2023-01-03 12:20 ` Oliver Neukum 2023-01-03 12:20 ` Oliver Neukum 2023-01-03 12:49 ` Takashi Iwai 2023-01-03 12:49 ` Takashi Iwai 2023-01-03 23:45 ` Wesley Cheng [this message] 2023-01-03 23:45 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 05/14] sound: usb: Export USB SND APIs for modules Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 6:48 ` Greg KH 2022-12-24 6:48 ` Greg KH 2022-12-23 23:31 ` [RFC PATCH 06/14] usb: core: hcd: Introduce USB HCD APIs for interrupter management Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:54 ` Greg KH 2022-12-24 8:54 ` Greg KH 2022-12-27 21:13 ` Wesley Cheng 2022-12-27 21:13 ` Wesley Cheng 2022-12-24 15:29 ` Alan Stern 2022-12-24 15:29 ` Alan Stern 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-28 8:59 ` Oliver Neukum 2022-12-28 8:59 ` Oliver Neukum 2022-12-28 15:16 ` Alan Stern 2022-12-28 15:16 ` Alan Stern 2022-12-28 20:31 ` Wesley Cheng 2022-12-28 20:31 ` Wesley Cheng 2022-12-29 1:41 ` Alan Stern 2022-12-29 1:41 ` Alan Stern 2022-12-23 23:31 ` [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 5:59 ` kernel test robot 2022-12-24 8:55 ` Greg KH 2022-12-24 8:55 ` Greg KH 2022-12-28 15:47 ` Mathias Nyman 2022-12-28 15:47 ` Mathias Nyman 2022-12-29 21:14 ` Wesley Cheng 2022-12-29 21:14 ` Wesley Cheng 2023-01-02 16:38 ` Mathias Nyman 2023-01-02 16:38 ` Mathias Nyman 2023-01-09 20:24 ` Wesley Cheng 2023-01-09 20:24 ` Wesley Cheng 2023-01-10 19:47 ` Mathias Nyman 2023-01-10 19:47 ` Mathias Nyman 2023-01-10 20:03 ` Wesley Cheng 2023-01-10 20:03 ` Wesley Cheng 2023-01-11 3:11 ` Wesley Cheng 2023-01-11 3:11 ` Wesley Cheng 2023-01-12 9:24 ` Mathias Nyman 2023-01-12 9:24 ` Mathias Nyman 2023-01-13 0:34 ` Wesley Cheng 2023-01-13 0:34 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 08/14] usb: dwc3: Add DT parameter to specify maximum number of interrupters Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 11:13 ` Dmitry Baryshkov 2022-12-24 11:13 ` Dmitry Baryshkov 2022-12-26 12:28 ` Krzysztof Kozlowski 2022-12-26 12:28 ` Krzysztof Kozlowski 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:06 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 09/14] sound: usb: Introduce QC USB SND offloading support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:27 ` kernel test robot 2023-01-02 17:28 ` Takashi Iwai 2023-01-02 17:28 ` Takashi Iwai 2023-01-04 22:38 ` Wesley Cheng 2023-01-04 22:38 ` Wesley Cheng 2023-01-04 23:51 ` Pierre-Louis Bossart 2023-01-06 1:06 ` Wesley Cheng 2023-01-06 1:06 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 10/14] sound: usb: card: Check for support for requested audio format Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:59 ` Greg KH 2022-12-24 8:59 ` Greg KH 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 20:31 ` kernel test robot 2022-12-23 23:31 ` [RFC PATCH 11/14] sound: soc: soc-usb: Add PCM format check API for USB backend Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:17 ` kernel test robot 2022-12-24 2:17 ` kernel test robot 2022-12-23 23:31 ` [RFC PATCH 12/14] sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio device Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:19 ` Sergey Shtylyov 2022-12-24 8:19 ` Sergey Shtylyov 2022-12-24 8:50 ` Wesley Cheng 2022-12-24 8:50 ` Wesley Cheng 2023-01-03 17:44 ` Mark Brown 2023-01-03 17:44 ` Mark Brown 2022-12-23 23:31 ` [RFC PATCH 13/14] ASoC: dt-bindings: Add Q6USB backend bindings Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-26 12:25 ` Krzysztof Kozlowski 2022-12-26 12:25 ` Krzysztof Kozlowski 2022-12-23 23:32 ` [RFC PATCH 14/14] ASoC: dt-bindings: Update example for enabling USB offload on SM8250 Wesley Cheng 2022-12-23 23:32 ` Wesley Cheng 2022-12-26 12:27 ` Krzysztof Kozlowski 2022-12-26 12:27 ` Krzysztof Kozlowski 2023-01-03 17:46 ` Mark Brown 2023-01-03 17:46 ` Mark Brown 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-04 0:46 ` Rob Herring 2023-01-04 0:46 ` Rob Herring 2022-12-24 6:45 ` [RFC PATCH 00/14] Introduce QC USB SND audio offloading support Greg KH 2022-12-24 6:45 ` Greg KH 2022-12-24 8:49 ` Wesley Cheng 2022-12-24 8:49 ` Wesley Cheng 2022-12-27 14:36 ` Mark Brown 2022-12-27 14:36 ` Mark Brown 2023-01-04 23:19 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 15:57 ` Pierre-Louis Bossart 2023-01-07 0:46 ` Wesley Cheng 2023-01-07 0:46 ` Wesley Cheng
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=54f36fe7-c590-3d5c-58dc-c5a02c412487@quicinc.com \ --to=quic_wcheng@quicinc.com \ --cc=Thinh.Nguyen@synopsys.com \ --cc=agross@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=andersson@kernel.org \ --cc=bgoswami@quicinc.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mathias.nyman@intel.com \ --cc=oneukum@suse.com \ --cc=perex@perex.cz \ --cc=quic_jackp@quicinc.com \ --cc=quic_plai@quicinc.com \ --cc=robh+dt@kernel.org \ --cc=srinivas.kandagatla@linaro.org \ --cc=tiwai@suse.com \ --cc=tiwai@suse.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.