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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF6EBC61DA3 for ; Thu, 26 Jan 2023 16:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232706AbjAZQZd (ORCPT ); Thu, 26 Jan 2023 11:25:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229551AbjAZQZ1 (ORCPT ); Thu, 26 Jan 2023 11:25:27 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DB376FD32; Thu, 26 Jan 2023 08:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674750278; x=1706286278; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=/S4O1xQUstj71vMufDuTxZtrxS0kRcuRW6nd5unpPcQ=; b=AmCfdeQeocHVhfSsg93d/Rm7qN6dqYBjSY1UHu4r3SxVrp5W+W/b9XQF Wqp/IWhAviJ3Yf+/6vMZA6oocqf4/m+/DVZnEymQrFT8VkzD6JbEsB5eN 1Kodt9rAz7BDDSI9WOofp6O9sUAw3gL+2vDiFdU3wTvFh6BgB3nFrnBA3 5iuF0uIuMkTGxsfOfUeqAcG2hHDZrXmRKl4oJRj2llQVfp/z5B8et64Xw bur4pgMLaqb8y5qXE3CVFF2q0K7FugF5bCpm+STOG4Rj+NKE6YZNwCS1b MNQZXGEuqKaztvJkvQszTHYJ/HdvfS5RbIkrB7LXbbjcM2hZtkC1oFb5T w==; X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="354154594" X-IronPort-AV: E=Sophos;i="5.97,248,1669104000"; d="scan'208";a="354154594" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2023 08:24:33 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="612855051" X-IronPort-AV: E=Sophos;i="5.97,248,1669104000"; d="scan'208";a="612855051" Received: from nmani1-mobl2.amr.corp.intel.com (HELO [10.209.167.178]) ([10.209.167.178]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2023 08:24:31 -0800 Message-ID: Date: Thu, 26 Jan 2023 09:38:57 -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 v2 09/22] 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, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, Thinh.Nguyen@synopsys.com, broonie@kernel.org, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org 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 References: <20230126031424.14582-1-quic_wcheng@quicinc.com> <20230126031424.14582-10-quic_wcheng@quicinc.com> From: Pierre-Louis Bossart In-Reply-To: <20230126031424.14582-10-quic_wcheng@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/25/23 21:14, Wesley Cheng wrote: > The QC ADSP is able to support USB playback endpoints, 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. > > Specifically, the QC ADSP can support all potential endpoints that are > exposed by the audio data interface. This includes, feedback endpoints > (both implicit and explicit) as well as the isochronous (data) endpoints. > The size of audio samples sent per USB frame (microframe) will be adjusted > based on information received on the feedback endpoint. I think you meant "support all potential endpoint types" It's likely that some USB devices have more endpoints than what the DSP can handle, no? And that brings me back to the question: what is a port and the relationship between port/backend/endpoints? Sorry for being picky on terminology, but if I learned something in days in standardization it's that there shouldn't be any ambiguity on concepts, otherwise everyone is lost at some point. > static struct afe_port_map port_maps[AFE_PORT_MAX] = { > + [USB_RX] = { AFE_PORT_ID_USB_RX, USB_RX, 1, 1}, > [HDMI_RX] = { AFE_PORT_ID_MULTICHAN_HDMI_RX, HDMI_RX, 1, 1}, > [SLIMBUS_0_RX] = { AFE_PORT_ID_SLIMBUS_MULTI_CHAN_0_RX, > SLIMBUS_0_RX, 1, 1}, And if I look here a port seems to be a very specific AFE concept related to interface type? Do we even need to refer to a port in the USB parts?