Message ID | 20231017200109.11407-35-quic_wcheng@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4370679vqb; Tue, 17 Oct 2023 13:04:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFTzf8UTUbhhCbT3SYzK1Z4bBwQMuI1lw9Bztyb5dITAGK7qdkHWs7V4EScPZTKl1OEiAMI X-Received: by 2002:a17:90b:4c91:b0:27d:3b8:a08a with SMTP id my17-20020a17090b4c9100b0027d03b8a08amr3512495pjb.1.1697573050059; Tue, 17 Oct 2023 13:04:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697573050; cv=none; d=google.com; s=arc-20160816; b=Jt1DzrLMcY7ojZloOKEdjFSkZVYh0dj5/xqbcS3IOhOjncYzjffuPWJ51D+Vd/tFvj Si6qR3uAfBfFn1J0ByA4aEyZvFDT5GLaLPg0UGWmag9aAi3zdPoaQJHuT11p/K8Cxy8X jiTAFf0sK6tfAXQVcX56Z5ynw6hFCpl9gcHc/Z1G7LhswguCq64p2FJkAjPkSv7gxaip 6JgF7pmgTvUvCGgeD44E6l5AzGgrQeNn3WaDkXF2s/Xpjb27NM8MjmJ6GCbXP5BLqYGn Jjn0WnWwrjleZq9MGUJWmDLsxvJqH9L2hF5p0W1U89FUoQlMBMEUqvS6H4HIuGu83/GS 5oRg== 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=DoJZgskjuTAjvQWKHDVwm5LpAAOTSIH3Fsab8vjZneA=; fh=ASZxE/GudOQkGCAz0d02NHHSpg4iNHYOcDWl1imlof0=; b=ondnfewfnn2qZWxqYYLryOkJLNBxapy5L5FlyxpubVftiy5u1UhG4orrA4IVvhhYaM d9ZKLMbkrYnuz4KKDhb+4sclMxVZUHiDkp/O/rhXl1E3tbMowOgt62gg0OREAACpSPzR xE8lC0g0Amc/LB6Z35JDoaafjYfmjajC0MkqibWcLLnmbWWJnBajn1RJoKhcO3L0J4Ts 1xd7mI9LE82R7rSWLrANvN/6G2AsUe5k9nrOP0u8QLd3fbwaJe6Wo8Crph033e9oVNxo 3kEV+AZAiNC47gDUGFjtdZM+51+M52Ur9sbDhQw0rKIxXPO9RHydvEJVRPhXjCKYmgzw px0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=VxijUOB6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id y7-20020a636407000000b005ac154f0ff4si522974pgb.119.2023.10.17.13.04.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 13:04:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=VxijUOB6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id B2CB6802D3A7; Tue, 17 Oct 2023 13:04:04 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235005AbjJQUDp (ORCPT <rfc822;dexuan.linux@gmail.com> + 21 others); Tue, 17 Oct 2023 16:03:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344157AbjJQUB5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Oct 2023 16:01:57 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89CDB121; Tue, 17 Oct 2023 13:01:51 -0700 (PDT) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39HJwCfa020201; Tue, 17 Oct 2023 20:01:32 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=DoJZgskjuTAjvQWKHDVwm5LpAAOTSIH3Fsab8vjZneA=; b=VxijUOB6EvlzWgGhMAQwya1NKWK+zZ2yF5E6BmGkG3zQKY0M71Vmd9gHhQlyGVVFY+k9 rJd8oJwXC/IJC+CvlblZD4DjswrsaEza8ZAtGoYu1sO6bJAuB5bXF9bCUYlEn9+IKiCA Uqiyj2aJuyfSfqV/TNHxrCaqCrCDbJd8d/i5zCOo5ZCh7VK5stHEeyFPGlaEjX9/8PO7 5CO58ZZgiNMnRKfM74iL2L0lAQYl3lirghZdjGrRQ50AeOars90uSkwZ/p2153BLj7Hl SnTkZfBBHK+17ElRxTkzHnmlu94vCm4s+NKnnfQ1T+biOw3TnKlppT4jvLCqTZrbfyvH cA== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3tsr7c1bbg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Oct 2023 20:01:31 +0000 Received: from nalasex01b.na.qualcomm.com (nalasex01b.na.qualcomm.com [10.47.209.197]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 39HK1UGt027424 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Oct 2023 20:01:30 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.1118.39; Tue, 17 Oct 2023 13:01:29 -0700 From: Wesley Cheng <quic_wcheng@quicinc.com> To: <mathias.nyman@intel.com>, <gregkh@linuxfoundation.org>, <lgirdwood@gmail.com>, <broonie@kernel.org>, <perex@perex.cz>, <tiwai@suse.com>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <srinivas.kandagatla@linaro.org>, <bgoswami@quicinc.com>, <Thinh.Nguyen@synopsys.com> CC: <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <alsa-devel@alsa-project.org>, <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>, Wesley Cheng <quic_wcheng@quicinc.com> Subject: [PATCH v9 34/34] ASoC: usb: Rediscover USB SND devices on USB port add Date: Tue, 17 Oct 2023 13:01:09 -0700 Message-ID: <20231017200109.11407-35-quic_wcheng@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20231017200109.11407-1-quic_wcheng@quicinc.com> References: <20231017200109.11407-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: bc8wjuo5QozTUjptIZKECPWLozquuHZJ X-Proofpoint-GUID: bc8wjuo5QozTUjptIZKECPWLozquuHZJ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-17_03,2023-10-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 bulkscore=0 adultscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310170170 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 17 Oct 2023 13:04:04 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780034358450071089 X-GMAIL-MSGID: 1780034358450071089 |
Series |
Introduce QC USB SND audio offloading support
|
|
Commit Message
Wesley Cheng
Oct. 17, 2023, 8:01 p.m. UTC
In case the USB backend device has not been initialized/probed, USB SND
device connections can still occur. When the USB backend is eventually
made available, previous USB SND device connections are not communicated to
the USB backend. Call snd_usb_rediscover_devices() to generate the connect
callbacks for all USB SND devices connected. This will allow for the USB
backend to be updated with the current set of devices available.
The chip array entries are all populated and removed while under the
register_mutex, so going over potential race conditions:
Thread#1:
q6usb_component_probe()
--> snd_soc_usb_add_port()
--> snd_usb_rediscover_devices()
--> mutex_lock(register_mutex)
Thread#2
--> usb_audio_disconnect()
--> mutex_lock(register_mutex)
So either thread#1 or thread#2 will complete first. If
Thread#1 completes before thread#2:
SOC USB will notify DPCM backend of the device connection. Shortly
after, once thread#2 runs, we will get a disconnect event for the
connected device.
Thread#2 completes before thread#1:
Then during snd_usb_rediscover_devices() it won't notify of any
connection for that particular chip index.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
---
sound/soc/soc-usb.c | 2 ++
1 file changed, 2 insertions(+)
Comments
On 10/17/23 15:01, Wesley Cheng wrote: > In case the USB backend device has not been initialized/probed, USB SND > device connections can still occur. When the USB backend is eventually > made available, previous USB SND device connections are not communicated to > the USB backend. Call snd_usb_rediscover_devices() to generate the connect > callbacks for all USB SND devices connected. This will allow for the USB > backend to be updated with the current set of devices available. > > The chip array entries are all populated and removed while under the > register_mutex, so going over potential race conditions: > > Thread#1: > q6usb_component_probe() > --> snd_soc_usb_add_port() > --> snd_usb_rediscover_devices() > --> mutex_lock(register_mutex) > > Thread#2 > --> usb_audio_disconnect() > --> mutex_lock(register_mutex) > > So either thread#1 or thread#2 will complete first. If > > Thread#1 completes before thread#2: > SOC USB will notify DPCM backend of the device connection. Shortly > after, once thread#2 runs, we will get a disconnect event for the > connected device. > > Thread#2 completes before thread#1: > Then during snd_usb_rediscover_devices() it won't notify of any > connection for that particular chip index. Looks like you are assuming the regular USB audio stuff is probed first? What if it's not the case? Have you tested with a manual 'blacklist' and "modprobe" sequence long after all the DSP stuff is initialized? It really reminds me of audio+display issues, and the same opens apply IMHO.
Hi Pierre, On 10/17/2023 4:11 PM, Pierre-Louis Bossart wrote: > > > On 10/17/23 15:01, Wesley Cheng wrote: >> In case the USB backend device has not been initialized/probed, USB SND >> device connections can still occur. When the USB backend is eventually >> made available, previous USB SND device connections are not communicated to >> the USB backend. Call snd_usb_rediscover_devices() to generate the connect >> callbacks for all USB SND devices connected. This will allow for the USB >> backend to be updated with the current set of devices available. >> >> The chip array entries are all populated and removed while under the >> register_mutex, so going over potential race conditions: >> >> Thread#1: >> q6usb_component_probe() >> --> snd_soc_usb_add_port() >> --> snd_usb_rediscover_devices() >> --> mutex_lock(register_mutex) >> >> Thread#2 >> --> usb_audio_disconnect() >> --> mutex_lock(register_mutex) >> >> So either thread#1 or thread#2 will complete first. If >> >> Thread#1 completes before thread#2: >> SOC USB will notify DPCM backend of the device connection. Shortly >> after, once thread#2 runs, we will get a disconnect event for the >> connected device. >> >> Thread#2 completes before thread#1: >> Then during snd_usb_rediscover_devices() it won't notify of any >> connection for that particular chip index. > Looks like you are assuming the regular USB audio stuff is probed first? > > What if it's not the case? Have you tested with a manual 'blacklist' and > "modprobe" sequence long after all the DSP stuff is initialized? > > It really reminds me of audio+display issues, and the same opens apply IMHO. Not necessarily...if the USB audio driver is not probed, then that is the same scenario as when there is no USB audio capable device plugged in, while the offload path is waiting for the connect event. I think this is the standard scenario. In the situation where the platform sound card hasn't probed yet and USB audio devices are being identified, then that is basically the scenario that would be more of an issue, since its USB SND that notifies of the connection state (at the time of connect/disconnect). I've tried with building these drivers as modules and probing them at different times/sequences, and I haven't seen an issue so far. Thanks Wesley Cheng
On 10/23/23 16:54, Wesley Cheng wrote: > Hi Pierre, > > On 10/17/2023 4:11 PM, Pierre-Louis Bossart wrote: >> >> >> On 10/17/23 15:01, Wesley Cheng wrote: >>> In case the USB backend device has not been initialized/probed, USB SND >>> device connections can still occur. When the USB backend is eventually >>> made available, previous USB SND device connections are not >>> communicated to >>> the USB backend. Call snd_usb_rediscover_devices() to generate the >>> connect >>> callbacks for all USB SND devices connected. This will allow for the >>> USB >>> backend to be updated with the current set of devices available. >>> >>> The chip array entries are all populated and removed while under the >>> register_mutex, so going over potential race conditions: >>> >>> Thread#1: >>> q6usb_component_probe() >>> --> snd_soc_usb_add_port() >>> --> snd_usb_rediscover_devices() >>> --> mutex_lock(register_mutex) >>> >>> Thread#2 >>> --> usb_audio_disconnect() >>> --> mutex_lock(register_mutex) >>> >>> So either thread#1 or thread#2 will complete first. If >>> >>> Thread#1 completes before thread#2: >>> SOC USB will notify DPCM backend of the device connection. Shortly >>> after, once thread#2 runs, we will get a disconnect event for the >>> connected device. >>> >>> Thread#2 completes before thread#1: >>> Then during snd_usb_rediscover_devices() it won't notify of any >>> connection for that particular chip index. >> Looks like you are assuming the regular USB audio stuff is probed first? >> >> What if it's not the case? Have you tested with a manual 'blacklist' and >> "modprobe" sequence long after all the DSP stuff is initialized? >> >> It really reminds me of audio+display issues, and the same opens apply >> IMHO. > > Not necessarily...if the USB audio driver is not probed, then that is > the same scenario as when there is no USB audio capable device plugged > in, while the offload path is waiting for the connect event. I think > this is the standard scenario. > > In the situation where the platform sound card hasn't probed yet and USB > audio devices are being identified, then that is basically the scenario > that would be more of an issue, since its USB SND that notifies of the > connection state (at the time of connect/disconnect). Not following if this scenario is covered? > I've tried with building these drivers as modules and probing them at > different times/sequences, and I haven't seen an issue so far. The scenario I have in mind is this: the platform driver is on the deny list, the USB driver detects a device. When the platform driver probes at a later time (with a manual modprobe to make delays really long), how would the notification be handled? Between audio and display, we use the 'drm_audio_component' layer to model these sort of run-time binding between independent driver stacks. It's not used here but we need a moral equivalent, don't we? It would really help if you documented a bit more the dependencies or timing assumptions, to make sure we have a stable solution to build on.
Hi Pierre, On 10/24/2023 6:35 AM, Pierre-Louis Bossart wrote: > > > On 10/23/23 16:54, Wesley Cheng wrote: >> Hi Pierre, >> >> On 10/17/2023 4:11 PM, Pierre-Louis Bossart wrote: >>> >>> >>> On 10/17/23 15:01, Wesley Cheng wrote: >>>> In case the USB backend device has not been initialized/probed, USB SND >>>> device connections can still occur. When the USB backend is eventually >>>> made available, previous USB SND device connections are not >>>> communicated to >>>> the USB backend. Call snd_usb_rediscover_devices() to generate the >>>> connect >>>> callbacks for all USB SND devices connected. This will allow for the >>>> USB >>>> backend to be updated with the current set of devices available. >>>> >>>> The chip array entries are all populated and removed while under the >>>> register_mutex, so going over potential race conditions: >>>> >>>> Thread#1: >>>> q6usb_component_probe() >>>> --> snd_soc_usb_add_port() >>>> --> snd_usb_rediscover_devices() >>>> --> mutex_lock(register_mutex) >>>> >>>> Thread#2 >>>> --> usb_audio_disconnect() >>>> --> mutex_lock(register_mutex) >>>> >>>> So either thread#1 or thread#2 will complete first. If >>>> >>>> Thread#1 completes before thread#2: >>>> SOC USB will notify DPCM backend of the device connection. Shortly >>>> after, once thread#2 runs, we will get a disconnect event for the >>>> connected device. >>>> >>>> Thread#2 completes before thread#1: >>>> Then during snd_usb_rediscover_devices() it won't notify of any >>>> connection for that particular chip index. >>> Looks like you are assuming the regular USB audio stuff is probed first? >>> >>> What if it's not the case? Have you tested with a manual 'blacklist' and >>> "modprobe" sequence long after all the DSP stuff is initialized? >>> >>> It really reminds me of audio+display issues, and the same opens apply >>> IMHO. >> >> Not necessarily...if the USB audio driver is not probed, then that is >> the same scenario as when there is no USB audio capable device plugged >> in, while the offload path is waiting for the connect event. I think >> this is the standard scenario. >> >> In the situation where the platform sound card hasn't probed yet and USB >> audio devices are being identified, then that is basically the scenario >> that would be more of an issue, since its USB SND that notifies of the >> connection state (at the time of connect/disconnect). > > Not following if this scenario is covered? > Yes, this is covered. For example, if there are already devices connected, but the platform sound card is still unbound. Then this rediscover API will be called to traverse through the list of connected USB sound devices, so that the USB DPCM dai can know about their existence when it is probed. >> I've tried with building these drivers as modules and probing them at >> different times/sequences, and I haven't seen an issue so far. > > The scenario I have in mind is this: > > the platform driver is on the deny list, the USB driver detects a > device. When the platform driver probes at a later time (with a manual > modprobe to make delays really long), how would the notification be handled? > So that is essentially the same scenario as when there is no USB device connected, ie no USB class driver is bounded to anything. Since the notifications are all handled within USB SND (USB class driver) then if the module isn't loaded yet, no notification is sent to the DPCM USB backend. Once you say...modprobe the USB SND driver, then the USB interface probe occurs, and that would issue the connect callback from the USB SND probe routine. (keep in mind these are not platform devices, we're working with devices under the usb bus) > Between audio and display, we use the 'drm_audio_component' layer to > model these sort of run-time binding between independent driver stacks. > It's not used here but we need a moral equivalent, don't we? > > It would really help if you documented a bit more the dependencies or > timing assumptions, to make sure we have a stable solution to build on. > I can add this to the RST that I'll make in detail, and add a summary here in the commit message. Thanks Wesley Cheng
diff --git a/sound/soc/soc-usb.c b/sound/soc/soc-usb.c index 7407678a993e..60aafbe87c36 100644 --- a/sound/soc/soc-usb.c +++ b/sound/soc/soc-usb.c @@ -104,6 +104,8 @@ struct snd_soc_usb *snd_soc_usb_add_port(struct device *dev, void *priv, list_add_tail(&usb->list, &usb_ctx_list); mutex_unlock(&ctx_mutex); + snd_usb_rediscover_devices(); + return usb; } EXPORT_SYMBOL_GPL(snd_soc_usb_add_port);