From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 21CC9C27C4F for ; Fri, 21 Jun 2024 08:30:21 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 8954BA4B; Fri, 21 Jun 2024 10:30:09 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 8954BA4B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1718958619; bh=wuZBbOonZAFOS0sB1XJO28DAm8t6RfuaFgesGkuVgmA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=aMOQUyQmxw9ezb2pnWRkMkSwJ3Utx9Q/n4r+6c5ekYtcokuEwjv/uNiU9KdvXDWQa fJz2b8EElwxcGDz0tsaTPgUousl6EFjlQCfxgZ6S1GU57BxwZC2nD4nqsQkr79Uqhd Ky49fapp3sIkC0tYGjTVrbKfzXm9UeN2Y2L9e4WY= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 557F9F805A1; Fri, 21 Jun 2024 10:29:47 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 71E79F805B3; Fri, 21 Jun 2024 10:29:45 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E085CF8023A; Fri, 21 Jun 2024 10:27:52 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 102A3F8010C for ; Fri, 21 Jun 2024 10:27:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 102A3F8010C Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=gH610E9o DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718958466; x=1750494466; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wuZBbOonZAFOS0sB1XJO28DAm8t6RfuaFgesGkuVgmA=; b=gH610E9oLq9q7L9IxOsDMHISKpzFk2UwejP79sTO//Mn9VwBa1SeVlaK XWBodpXnXjPKKTywoXpZ+ibiF2whfwGT0D/HmQqPDnPL8rmhAdCu5TV5u rWnSjz38jWvCXDl4EuUVBiEFqEu/yjap1mkQTzm/APqLeRg83CkZqrony Yt3s2pB865n6OgXW20bTxifizhvXxy6mZ2IVN64MEUqgKkWkzaxfn6Qru 9dlYtTkamSj0866leUdcTIvU09uvwC9KdGiWV3xm9bYuGVHtLhQpm7TYs 4I/lEeEo4czA2uN6E9QYXkYVPRlPJ32Y3J7lukHbT2nlATdsg+Ykaf6ST w==; X-CSE-ConnectionGUID: B6wmwC1oT3mya7e8w5rxww== X-CSE-MsgGUID: ycBi1PTPSOuSEV61VxPKZA== X-IronPort-AV: E=McAfee;i="6700,10204,11109"; a="33438311" X-IronPort-AV: E=Sophos;i="6.08,254,1712646000"; d="scan'208";a="33438311" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2024 01:27:38 -0700 X-CSE-ConnectionGUID: 83RXG4JlThiu0gr95hxjnw== X-CSE-MsgGUID: bZhtUY6HTEaIIglKI2p5DA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,254,1712646000"; d="scan'208";a="42628778" Received: from bergbenj-mobl1.ger.corp.intel.com (HELO [10.245.246.142]) ([10.245.246.142]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2024 01:27:33 -0700 Message-ID: <90463a4e-c2e7-4b59-9a79-23533b4acd1e@linux.intel.com> Date: Fri, 21 Jun 2024 10:27:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB To: Wesley Cheng , =?UTF-8?Q?Amadeusz_S=C5=82awi=C5=84ski?= , srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, conor+dt@kernel.org, corbet@lwn.net, broonie@kernel.org, lgirdwood@gmail.com, krzk+dt@kernel.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh@kernel.org, gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-sound@vger.kernel.org, linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org, alsa-devel@alsa-project.org References: <20240610235808.22173-1-quic_wcheng@quicinc.com> <20240610235808.22173-33-quic_wcheng@quicinc.com> <5be51e1f-70c9-4bbc-96fa-1e50e441bd35@linux.intel.com> <408d9e8e-0f40-7e66-54be-2f8d2c0783a3@quicinc.com> <096d59a0-5e18-092c-c9ae-d98130226f06@quicinc.com> <368d9019-2c96-468e-b472-7e1127f76213@linux.intel.com> <510468c7-b181-48d0-bf2d-3e478b2f2aca@linux.intel.com> Content-Language: en-US From: Pierre-Louis Bossart In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID-Hash: 54GDNKSMPSK2FBYTNACSAHR2X36GZDXV X-Message-ID-Hash: 54GDNKSMPSK2FBYTNACSAHR2X36GZDXV X-MailFrom: pierre-louis.bossart@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > I'll spend some time to evaluate your suggestion about moving the logic > to control the offloading from USB SND versus ASoC, since there are > valid points.  However, before I do that, I just want to make sure folks > are also inline with that thinking.  I've had to put a lot of effort > moving things around such as the previous example, and now you've > suggested to move it back to the vendor specific drivers. > > @Pierre, since you've helped with providing a lot of valuable input in > the previous revisions on the kcontrol uses, what do you think about the > proposal from Amadeusz?  Basically shifting the offload device selection > into USB SND from the ASoC USB BE driver, and having this per USB SND > device. > > [1] > https://lore.kernel.org/linux-usb/20231017200109.11407-30-quic_wcheng@quicinc.com/ This thread is very hard to follow, I am not sure I fully understood the initial proposal, and I am not sure I follow Amadeusz' either. There are really multiple layers to deal with a) is the controller able to support the offload path? IIRC this is embedded in an obscure XHCI property, it would make sense to expose it as a control, or component string, of the USB card. b) is there a companion card capable of dealing with the offload path? Since the presence of this card may depend on driver probe, there should be a control on the USB card. userspace could detect changes to this control and detect if that path is or is no longer enabled. c) which PCM device is actually offloaded? This could be plural for some implementations. The mapping between PCM devices exposed by the USB card, and those exposed by the companion card, should be known to userspace. I am not sure how this would be done though, a variable number of controls is a sure way to confuse userspace. At any rate, I would put all the controls under the USB generic card, because it's always present no matter what the controller or DSP configurations are.