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 9BEC0C61DB3 for ; Fri, 6 Jan 2023 23:59:04 +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 5FF4914C75; Sat, 7 Jan 2023 00:58:12 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 5FF4914C75 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1673049542; bh=5YAuWiDjAal/uJrXM9ILONLLrQCsDzm/BE7yygN0SAs=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=AHWtNViYHw0mNm8v0F+eSqEQ5+NsdiilyTgdba5zYOaT1lv+eSnaoFVVsqA4YuLOB H5bwL+b4T1Q7KX/eudmndolUmW4Y8hpA4iX19eduebYB5palx+CHby5Tr5BUUinxaX xxaB1dM3c9oKD4+H0F952sWBq4hWQ/Mvdzy+0X8I= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id DBA28F8025A; Sat, 7 Jan 2023 00:57:47 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 12CB2F8024E; Sat, 7 Jan 2023 00:57:45 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 D1790F80217 for ; Sat, 7 Jan 2023 00:57:36 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz D1790F80217 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=ar8+4HJQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673049458; x=1704585458; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5YAuWiDjAal/uJrXM9ILONLLrQCsDzm/BE7yygN0SAs=; b=ar8+4HJQAKtjzeA0wkJkzxgOpyxwotB2q10TnuF+BGrByGurwpsqgavL zJg7duwhMIwOvCriTSwz9KpAo4ldP/TDtnJ9pbzAFblsMElzNTYmQnC4Q OTLkn2V1IvD1ITBWIuj92yps0QBQ36JBfqacJBuvV+XGOlwe3ZIk+IZgE 1W9fGooDbuUcOoorB2J3OAcLUOERCkVHtrF/pKeteI6triusnTvOaIo34 +WaolAkrQngGxM1hf7hxV58i5TQtiQ857TAtJ5JGCGB26D5ZpbA6cL5aN hfYHGPxC9ei7+AlrYYjYP2IWwOjZn+G1OhRtt1dJ6KNCB6v/YbyI8INXa Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="387047030" X-IronPort-AV: E=Sophos;i="5.96,306,1665471600"; d="scan'208";a="387047030" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 15:57:32 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="984817926" X-IronPort-AV: E=Sophos;i="5.96,306,1665471600"; d="scan'208";a="984817926" Received: from apbaezbo-mobl2.amr.corp.intel.com (HELO [10.212.60.153]) ([10.212.60.153]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 15:57:31 -0800 Message-ID: <65820e0e-be8b-c574-98d0-a2e60ee4be76@linux.intel.com> Date: Fri, 6 Jan 2023 10:09:21 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 Subject: Re: [RFC PATCH 02/14] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp Content-Language: en-US To: Wesley Cheng , 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 References: <20221223233200.26089-1-quic_wcheng@quicinc.com> <20221223233200.26089-3-quic_wcheng@quicinc.com> <5babccd6-9796-7613-cf82-cc859f338448@linux.intel.com> <6e13521a-84bf-f8a6-e8cc-5b90ff4bd675@quicinc.com> From: Pierre-Louis Bossart In-Reply-To: <6e13521a-84bf-f8a6-e8cc-5b90ff4bd675@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" >>> The QC ADSP is able to support USB playback and capture, so that the >>> main application processor can be placed into lower CPU power modes.  >>> This >>> adds the required AFE port configurations and port start command to >>> start >>> an audio session. >> >> It would be good to clarify what sort of endpoints can be supported. I >> presume the SOF-synchronous case is handled, but how would you deal with >> async endpoints with feedback (be it explicit or implicit)? >> > > Sure, both types of feedback endpoints are expected to be supported by > the audio DSP, as well as sync eps.  We have the logic there to modify > the audio sample size accordingly. did you mean modify samples per USB frame (or uframe), so as to change the pace at which data is transferred? If yes it'd be the same for Intel. >>>     static const struct snd_soc_dapm_route q6afe_dapm_routes[] = { >>> +    {"USB Playback", NULL, "USB_RX"}, >> >> ... but here RX means playback? >> >> I am not sure I get the convention on directions and what is actually >> supported? >> > > The notation is based on the direction of which the audio data is > sourced or pushed on to the DSP.  So in playback, the DSP is receiving > audio data to send, and capture, it is transmitting audio data received. > (although we do not support capture yet) ok, it'd be good to add a comment on this convention. Usually RX/TX is bus-centric. > >>> +struct afe_param_id_usb_cfg { >>> +/* Minor version used for tracking USB audio device configuration. >>> + * Supported values: AFE_API_MINOR_VERSION_USB_AUDIO_CONFIG >>> + */ >>> +    u32                  cfg_minor_version; >>> +/* Sampling rate of the port. >>> + * Supported values: >>> + * - AFE_PORT_SAMPLE_RATE_8K >>> + * - AFE_PORT_SAMPLE_RATE_11025 >>> + * - AFE_PORT_SAMPLE_RATE_12K >>> + * - AFE_PORT_SAMPLE_RATE_16K >>> + * - AFE_PORT_SAMPLE_RATE_22050 >>> + * - AFE_PORT_SAMPLE_RATE_24K >>> + * - AFE_PORT_SAMPLE_RATE_32K >>> + * - AFE_PORT_SAMPLE_RATE_44P1K >>> + * - AFE_PORT_SAMPLE_RATE_48K >>> + * - AFE_PORT_SAMPLE_RATE_96K >>> + * - AFE_PORT_SAMPLE_RATE_192K >>> + */ >>> +    u32                  sample_rate; >>> +/* Bit width of the sample. >>> + * Supported values: 16, 24 >>> + */ >>> +    u16                  bit_width; >>> +/* Number of channels. >>> + * Supported values: 1 and 2 >> >> that aligns with my feedback on the cover letter, if you connect a >> device that can support from than 2 channels should the DSP even expose >> this DSP-optimized path? >> > > My assumption is that I programmed the DAIs w/ PCM formats supported by > the DSP, so I think the ASoC core should not allow userspace to choose > that path if the hw params don't fit/match. Right, but the point I was trying to make is that if the device can do more, why create this DSP path at all? > >> Oh and I forgot, what happens if there are multiple audio devices >> connected, can the DSP deal with all of them? If not, how is this >> handled? >> > > This is one topic that we were pretty open ended on.  At least on our > implementation, only one audio device can be supported at a time.  We > choose the latest device that was plugged in or discovered by the USB > SND class driver. Similar case for Intel. I have to revisit this, I don't recall the details. >>> +    u32                  dev_token; >>> +/* endianness of this interface */ >>> +    u32                   endian; >> >> Is this a USB concept? I can't recall having seen any parts of the USB >> audio class spec that the data can be big or little endian? >> > > No, this is probably just something our audio DSP uses on the AFE > commands that it receives. ok.