Message ID | 20221223233200.26089-5-quic_wcheng@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6000:1b02:0:0:0:0 with SMTP id f2csp32237wrz; Fri, 23 Dec 2022 15:34:17 -0800 (PST) X-Google-Smtp-Source: AMrXdXtiM1hVro/yC6Ug2qJZ/+D6bf1k8jT0SqYLa8xMzXS7NwoMx+nJFF0NbDMrL5poR9qjirwT X-Received: by 2002:a17:907:d311:b0:829:5e3f:3c92 with SMTP id vg17-20020a170907d31100b008295e3f3c92mr11883478ejc.73.1671838457451; Fri, 23 Dec 2022 15:34:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671838457; cv=none; d=google.com; s=arc-20160816; b=U3MtVj0/aPGfg0/k8YfBUn3P97mc9J1BwVVotZKHX+O3BD8pt2bMO/Wo6T7vZYWiWR Ex8MwgLc+HMb0iUeRvgs80G5c6S3clsUHsKsTX6dEnz3CjFPaPoqtVCHdv7N3QlRdKRd N0mI+VAB1fF7x2khj3Sk5dkFWtCC7ITbVXldrVdY0ShrlpPCp+TaK1z1RPxhkXYFALyi 7usuhIpBR+vR6CukZC3UFQjW0msiQfLaSnI2MnZo6Hxu5//hs1xMeTFJZMGzXn5TzbKV TEA785evNcKmYBw5e8Ss482fdSH+RiVDtgsq/t05CE7Edn4eNJtrcIJi0ziCoL+muEcP //rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=VDTU3XTvrpxIwL9qSgdsrGb/DCechmiUc86IBF326RE=; b=0a0SdWtWfDuN9u5IribyS3TkXIe7W1QmdBeP9qsvI2Hle0vkEzA3ftr/VGa0ecD6Ze zl40ZSZiE40Ek4UWH6qWa2wDJarc0kOwRP9STMBG0JsbWVpZG0A7CsqhwehhM7MS7U5K bJIEm5Qz6Gvtp0zPsKm6Xn68PMAcT8gVUUeGiSm55SkIsese61OPjau8hid7GkbKkUYZ TTHyzo/LVk7/6k71apn+3abQuS5WrVV/ZXb6kLmbUy7IKKzFjk/hRrGnP9o6gdKrNIpL pX/4fU5PeuEqquPS2HHKTxhTNxtfU3gv1Afz8EGJ6Wy69dz06g0VUj+I+GkCa5tAXZQn 6azw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ik0uMp9X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xf13-20020a17090731cd00b007c11812c621si2980751ejb.459.2022.12.23.15.33.53; Fri, 23 Dec 2022 15:34:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ik0uMp9X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233096AbiLWXdX (ORCPT <rfc822;pacteraone@gmail.com> + 99 others); Fri, 23 Dec 2022 18:33:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231264AbiLWXdM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Dec 2022 18:33:12 -0500 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C084911147; Fri, 23 Dec 2022 15:33:10 -0800 (PST) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BNNTkUF005599; Fri, 23 Dec 2022 23:32:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=VDTU3XTvrpxIwL9qSgdsrGb/DCechmiUc86IBF326RE=; b=ik0uMp9XBeifrLb4j+xHORc3/viVy0uPBlSEQ6YlTEik6YZl4JPlddxPq33h3xe5zPBw YOT7XkZgb8hls3Vcl/LSopViFaQjQ/hM26u987RGI6ovHsaDH598aNGp336vbKAcd2Et +gm7tsFxKfTyQmA1FQ+o3sXSzcZjOFWnZGuEzcjbMXV6ySPF5f3GScpDu3JJShlRvYjt GF2PrzcSw4mKEJ/3Mq6CA8N1UCwmap43ZW3L2NqIYZSvOhxlzArD5+dsyHGEdKLqXBM8 gqI2PIaXvN9HgBOL5T82S7Nba85EpF7aEnxMgQoFtYKf3pYzstP1/hPuiAEu/lb3HSnK lg== Received: from nalasppmta05.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3mn2pga503-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Dec 2022 23:32:45 +0000 Received: from nalasex01b.na.qualcomm.com (nalasex01b.na.qualcomm.com [10.47.209.197]) by NALASPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 2BNNWiSp001844 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Dec 2022 23:32:44 GMT Received: from hu-wcheng-lv.qualcomm.com (10.49.16.6) by nalasex01b.na.qualcomm.com (10.47.209.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Fri, 23 Dec 2022 15:32:44 -0800 From: Wesley Cheng <quic_wcheng@quicinc.com> To: <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> CC: <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>, Wesley Cheng <quic_wcheng@quicinc.com> Subject: [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op callbacks Date: Fri, 23 Dec 2022 15:31:50 -0800 Message-ID: <20221223233200.26089-5-quic_wcheng@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221223233200.26089-1-quic_wcheng@quicinc.com> References: <20221223233200.26089-1-quic_wcheng@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.49.16.6] X-ClientProxiedBy: nalasex01a.na.qualcomm.com (10.47.209.196) To nalasex01b.na.qualcomm.com (10.47.209.197) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: kfEueJdQT5jZwiwFMYsDioxhTJ9T-uCV X-Proofpoint-GUID: kfEueJdQT5jZwiwFMYsDioxhTJ9T-uCV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-23_08,2022-12-23_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 bulkscore=0 adultscore=0 impostorscore=0 mlxlogscore=906 lowpriorityscore=0 suspectscore=0 mlxscore=0 phishscore=0 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212230197 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753049682269193940?= X-GMAIL-MSGID: =?utf-8?q?1753049682269193940?= |
Series |
Introduce QC USB SND audio offloading support
|
|
Commit Message
Wesley Cheng
Dec. 23, 2022, 11:31 p.m. UTC
Allow for different vendors to be notified on USB SND connect/disconnect
seqeunces. This allows for vendor USB SND modules to properly initialize
and populate internal structures with references to the USB SND chip
device.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
---
sound/usb/card.c | 22 ++++++++++++++++++++++
sound/usb/card.h | 7 +++++++
2 files changed, 29 insertions(+)
Comments
Hi, On Sat, 24 Dec 2022 at 01:33, Wesley Cheng <quic_wcheng@quicinc.com> wrote: > > Allow for different vendors to be notified on USB SND connect/disconnect > seqeunces. This allows for vendor USB SND modules to properly initialize > and populate internal structures with references to the USB SND chip > device. The commit message definitely needs some improvement. We do not notify vendors on SND connect/disconnect events. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > --- > sound/usb/card.c | 22 ++++++++++++++++++++++ > sound/usb/card.h | 7 +++++++ > 2 files changed, 29 insertions(+) > > diff --git a/sound/usb/card.c b/sound/usb/card.c > index 26268ffb8274..212f55a7683c 100644 > --- a/sound/usb/card.c > +++ b/sound/usb/card.c > @@ -117,6 +117,21 @@ MODULE_PARM_DESC(skip_validation, "Skip unit descriptor validation (default: no) > static DEFINE_MUTEX(register_mutex); > static struct snd_usb_audio *usb_chip[SNDRV_CARDS]; > static struct usb_driver usb_audio_driver; > +static struct snd_usb_vendor_ops *vendor_ops; > + > +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops) platform ops? > +{ > + vendor_ops = ops; > + return 0; > +} > +EXPORT_SYMBOL_GPL(snd_usb_register_vendor_ops); What happens if several platforms try to register different ops? I saw from the patch 09/14 that you register these ops unconditionally. If other devices follow your approach there is an obvious conflict. > + > +int snd_usb_unregister_vendor_ops(void) > +{ > + vendor_ops = NULL; > + return 0; > +} > +EXPORT_SYMBOL_GPL(snd_usb_unregister_vendor_ops); > > /* > * disconnect streams > @@ -910,6 +925,10 @@ static int usb_audio_probe(struct usb_interface *intf, > usb_set_intfdata(intf, chip); > atomic_dec(&chip->active); > mutex_unlock(®ister_mutex); > + > + if (vendor_ops->connect_cb) > + vendor_ops->connect_cb(intf, chip); > + > return 0; > > __error: > @@ -943,6 +962,9 @@ static void usb_audio_disconnect(struct usb_interface *intf) > if (chip == USB_AUDIO_IFACE_UNUSED) > return; > > + if (vendor_ops->disconnect_cb) > + vendor_ops->disconnect_cb(intf); > + > card = chip->card; > > mutex_lock(®ister_mutex); > diff --git a/sound/usb/card.h b/sound/usb/card.h > index 40061550105a..a785bb256b0d 100644 > --- a/sound/usb/card.h > +++ b/sound/usb/card.h > @@ -206,4 +206,11 @@ struct snd_usb_stream { > struct list_head list; > }; > > +struct snd_usb_vendor_ops { > + void (*connect_cb)(struct usb_interface *intf, struct snd_usb_audio *chip); > + void (*disconnect_cb)(struct usb_interface *intf); > +}; > + > +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops); > +int snd_usb_unregister_vendor_ops(void); > #endif /* __USBAUDIO_CARD_H */ -- With best wishes Dmitry
Hi Dmitry, On 12/24/2022 3:03 AM, Dmitry Baryshkov wrote: > Hi, > > On Sat, 24 Dec 2022 at 01:33, Wesley Cheng <quic_wcheng@quicinc.com> wrote: >> >> Allow for different vendors to be notified on USB SND connect/disconnect >> seqeunces. This allows for vendor USB SND modules to properly initialize >> and populate internal structures with references to the USB SND chip >> device. > > The commit message definitely needs some improvement. We do not notify > vendors on SND connect/disconnect events. > > >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >> --- >> sound/usb/card.c | 22 ++++++++++++++++++++++ >> sound/usb/card.h | 7 +++++++ >> 2 files changed, 29 insertions(+) >> >> diff --git a/sound/usb/card.c b/sound/usb/card.c >> index 26268ffb8274..212f55a7683c 100644 >> --- a/sound/usb/card.c >> +++ b/sound/usb/card.c >> @@ -117,6 +117,21 @@ MODULE_PARM_DESC(skip_validation, "Skip unit descriptor validation (default: no) >> static DEFINE_MUTEX(register_mutex); >> static struct snd_usb_audio *usb_chip[SNDRV_CARDS]; >> static struct usb_driver usb_audio_driver; >> +static struct snd_usb_vendor_ops *vendor_ops; >> + >> +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops) > > platform ops? > Will change it. >> +{ >> + vendor_ops = ops; >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(snd_usb_register_vendor_ops); > > What happens if several platforms try to register different ops? I saw > from the patch 09/14 that you register these ops unconditionally. If > other devices follow your approach there is an obvious conflict. > Thank you for the review. That is true. I don't think there is a proper need to have multiple vendor ops being registered, so maybe just returning an error for if ops are already registered is sufficient. Thanks Wesley Cheng
On 27/12/2022 23:07, Wesley Cheng wrote: > Hi Dmitry, > > On 12/24/2022 3:03 AM, Dmitry Baryshkov wrote: >> Hi, >> >> On Sat, 24 Dec 2022 at 01:33, Wesley Cheng <quic_wcheng@quicinc.com> >> wrote: >>> >>> Allow for different vendors to be notified on USB SND connect/disconnect >>> seqeunces. This allows for vendor USB SND modules to properly >>> initialize >>> and populate internal structures with references to the USB SND chip >>> device. >> >> The commit message definitely needs some improvement. We do not notify >> vendors on SND connect/disconnect events. >> >> >>> >>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>> --- >>> sound/usb/card.c | 22 ++++++++++++++++++++++ >>> sound/usb/card.h | 7 +++++++ >>> 2 files changed, 29 insertions(+) >>> >>> diff --git a/sound/usb/card.c b/sound/usb/card.c >>> index 26268ffb8274..212f55a7683c 100644 >>> --- a/sound/usb/card.c >>> +++ b/sound/usb/card.c >>> @@ -117,6 +117,21 @@ MODULE_PARM_DESC(skip_validation, "Skip unit >>> descriptor validation (default: no) >>> static DEFINE_MUTEX(register_mutex); >>> static struct snd_usb_audio *usb_chip[SNDRV_CARDS]; >>> static struct usb_driver usb_audio_driver; >>> +static struct snd_usb_vendor_ops *vendor_ops; >>> + >>> +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops) >> >> platform ops? >> > > Will change it. > >>> +{ >>> + vendor_ops = ops; >>> + return 0; >>> +} >>> +EXPORT_SYMBOL_GPL(snd_usb_register_vendor_ops); >> >> What happens if several platforms try to register different ops? I saw >> from the patch 09/14 that you register these ops unconditionally. If >> other devices follow your approach there is an obvious conflict. >> > > Thank you for the review. > > That is true. I don't think there is a proper need to have multiple > vendor ops being registered, so maybe just returning an error for if ops > are already registered is sufficient. This would be a required step. And also you have to check the running platform before registering your ops unconditionally. Ideally this should be done as a part of the device's driver, so that we can control registration of the platform ops using the usual interface. > > Thanks > Wesley Cheng
On 24.12.22 00:31, Wesley Cheng wrote: > Allow for different vendors to be notified on USB SND connect/disconnect > seqeunces. This allows for vendor USB SND modules to properly initialize > and populate internal structures with references to the USB SND chip > device. Hi, this raises a design question. If the system is suspending or, worse, hibernating, how do you make sure the offloader and the device are suspended in the correct order? And what happens if you need to go into reset_resume() when resuming? Regards Oliver
On Thu, 29 Dec 2022 14:49:21 +0100, Oliver Neukum wrote: > > > > On 24.12.22 00:31, Wesley Cheng wrote: > > Allow for different vendors to be notified on USB SND connect/disconnect > > seqeunces. This allows for vendor USB SND modules to properly initialize > > and populate internal structures with references to the USB SND chip > > device. > > Hi, > > this raises a design question. If the system is suspending or, worse, > hibernating, how do you make sure the offloader and the device are > suspended in the correct order? > And what happens if you need to go into reset_resume() when resuming? I guess we'd need to establish a device link when the binding from the offload driver is done. Then the PM order will be assured. Takashi
Hi, On 12/29/2022 6:20 AM, Takashi Iwai wrote: > On Thu, 29 Dec 2022 14:49:21 +0100, > Oliver Neukum wrote: >> >> >> >> On 24.12.22 00:31, Wesley Cheng wrote: >>> Allow for different vendors to be notified on USB SND connect/disconnect >>> seqeunces. This allows for vendor USB SND modules to properly initialize >>> and populate internal structures with references to the USB SND chip >>> device. >> >> Hi, >> >> this raises a design question. If the system is suspending or, worse, >> hibernating, how do you make sure the offloader and the device are >> suspended in the correct order? >> And what happens if you need to go into reset_resume() when resuming? 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. I would need to add some suspend handling in the offload driver to issue the command to stop the offloading. As for the resume path, is there a concern if either device is resumed first? The only scenario where maybe it could cause some mishandling is if the USB backend is resumed before the offload driver is connected/resumed. This means that the userspace ALSA would have access to the platform sound card, and could potentially attempt to route audio streams to it. I think in worst case, if we were going through a reset_resume() we would end up rejecting that request coming from the audio DSP to enable the stream. However, userspace entities would be resumed/unfrozen last, so not sure if that would ever be a problem. 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. Thanks Wesley Cheng
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. > 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() Regards Oliver
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. > > > > 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. Takashi
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
diff --git a/sound/usb/card.c b/sound/usb/card.c index 26268ffb8274..212f55a7683c 100644 --- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -117,6 +117,21 @@ MODULE_PARM_DESC(skip_validation, "Skip unit descriptor validation (default: no) static DEFINE_MUTEX(register_mutex); static struct snd_usb_audio *usb_chip[SNDRV_CARDS]; static struct usb_driver usb_audio_driver; +static struct snd_usb_vendor_ops *vendor_ops; + +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops) +{ + vendor_ops = ops; + return 0; +} +EXPORT_SYMBOL_GPL(snd_usb_register_vendor_ops); + +int snd_usb_unregister_vendor_ops(void) +{ + vendor_ops = NULL; + return 0; +} +EXPORT_SYMBOL_GPL(snd_usb_unregister_vendor_ops); /* * disconnect streams @@ -910,6 +925,10 @@ static int usb_audio_probe(struct usb_interface *intf, usb_set_intfdata(intf, chip); atomic_dec(&chip->active); mutex_unlock(®ister_mutex); + + if (vendor_ops->connect_cb) + vendor_ops->connect_cb(intf, chip); + return 0; __error: @@ -943,6 +962,9 @@ static void usb_audio_disconnect(struct usb_interface *intf) if (chip == USB_AUDIO_IFACE_UNUSED) return; + if (vendor_ops->disconnect_cb) + vendor_ops->disconnect_cb(intf); + card = chip->card; mutex_lock(®ister_mutex); diff --git a/sound/usb/card.h b/sound/usb/card.h index 40061550105a..a785bb256b0d 100644 --- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -206,4 +206,11 @@ struct snd_usb_stream { struct list_head list; }; +struct snd_usb_vendor_ops { + void (*connect_cb)(struct usb_interface *intf, struct snd_usb_audio *chip); + void (*disconnect_cb)(struct usb_interface *intf); +}; + +int snd_usb_register_vendor_ops(struct snd_usb_vendor_ops *ops); +int snd_usb_unregister_vendor_ops(void); #endif /* __USBAUDIO_CARD_H */