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

[Wesley Cheng <quic_wcheng@xxxxxxxxxxx>]

Hi Albert,

On 3/13/2024 1:03 AM, Albert Wang wrote:
> +/**
> + * qc_usb_audio_offload_suspend() - USB offload PM suspend handler
> + * @intf: USB interface
> + * @message: suspend type
> + *
> + * PM suspend handler to ensure that the USB offloading driver is able to stop
> + * any pending traffic, so that the bus can be suspended.
> + *
> + */
> +static void qc_usb_audio_offload_suspend(struct usb_interface *intf,
> +                                               pm_message_t message)
> +{
> +       struct qmi_uaudio_stream_ind_msg_v01 disconnect_ind = {0};
> +       struct snd_usb_audio *chip = usb_get_intfdata(intf);
> +       struct uaudio_qmi_svc *svc = uaudio_svc;
> +       struct uaudio_dev *dev;
> +       int card_num;
> +       int ret;
> +
> +       if (!chip)
> +               return;
> +
> +       card_num = chip->card->number;
> +       if (card_num >= SNDRV_CARDS)
> +               return;
> +
> +
> +       mutex_lock(&chip->mutex);
> +       dev = &uadev[card_num];
> +
> +       if (atomic_read(&dev->in_use)) {
> +               mutex_unlock(&chip->mutex);
> +               dev_dbg(uaudio_qdev->data->dev, "sending qmi
> indication suspend\n");
> +               disconnect_ind.dev_event = USB_QMI_DEV_DISCONNECT_V01;
> +               disconnect_ind.slot_id = dev->udev->slot_id;
> +               disconnect_ind.controller_num = dev->usb_core_id;
> +               disconnect_ind.controller_num_valid = 1;
> +               ret = qmi_send_indication(svc->uaudio_svc_hdl, &svc->client_sq,
> +                               QMI_UAUDIO_STREAM_IND_V01,
> +                               QMI_UAUDIO_STREAM_IND_MSG_V01_MAX_MSG_LEN,
> +                               qmi_uaudio_stream_ind_msg_v01_ei,
> +                               &disconnect_ind);
> +               if (ret < 0)
> +                       dev_err(uaudio_qdev->data->dev,
> +                               "qmi send failed with err: %d\n", ret);
> +
> +               ret = wait_event_interruptible_timeout(dev->disconnect_wq,
> +                               !atomic_read(&dev->in_use),
> +                               msecs_to_jiffies(DEV_RELEASE_WAIT_TIMEOUT));
> +               if (!ret) {
> +                       dev_err(uaudio_qdev->data->dev,
> +                               "timeout while waiting for dev_release\n");
> +                       atomic_set(&dev->in_use, 0);
> +               } else if (ret < 0) {
> +                       dev_err(uaudio_qdev->data->dev,
> +                               "failed with ret %d\n", ret);
> +                               atomic_set(&dev->in_use, 0);
> +               }
> +               mutex_lock(&chip->mutex);
> +       }
> +       mutex_unlock(&chip->mutex);
> +}
> +
>
> 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.

> 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