Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <c39df4c7-ea78-0505-a8d9-db41119fc977@quicinc.com>
Date:   Thu, 19 Oct 2023 11:42:22 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH v9 09/34] ASoC: qcom: qdsp6: Introduce USB AFE port to
 q6dsp
Content-Language: en-US
To:     Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        <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>
References: <20231017200109.11407-1-quic_wcheng@quicinc.com>
 <20231017200109.11407-10-quic_wcheng@quicinc.com>
 <7aa4ea87-9d1f-400a-bcc5-b56e5b4500c6@linux.intel.com>
 <c72bcf47-af0b-8819-1c30-06b51358381e@quicinc.com>
 <2f05708e-3ee8-472e-a24f-6f3eb118133c@linux.intel.com>
 <fcaa93ba-3ca4-5a18-d3bd-afebe8def327@quicinc.com>
 <ec25bb67-6c83-430b-bc79-234c03801250@linux.intel.com>
From:   Wesley Cheng <quic_wcheng@quicinc.com>
In-Reply-To: <ec25bb67-6c83-430b-bc79-234c03801250@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Pierre,

On 10/18/2023 6:00 PM, Pierre-Louis Bossart wrote:
> 
> 
>>>>>> 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.
>>>>>
>>>>> implicit feedback means support for capture. This is confusing...
>>>>>
>>>>
>>>> I mean, a USB device can expose a capture path, but as of now, we won't
>>>> enable the offloading to the audio DSP for it.  However, if we're
>>>> executing playback, and device does support implicit feedback, we will
>>>> pass that along to the audio DSP to utilize.
>>>
>>> Not following. Implicit feedback means a capture stream *SHALL* be
>>> started. Are you saying this capture stream is hidden and handled at the
>>> DSP level only? If yes, what prevents you from exposing the capture
>>> stream to userspace as well?
>>>
>>> I must be missing something.
>>>
>>
>> My understanding is that with implicit feedback endpoints, it allows for
>> another data endpoint in the opposite direction to be utilized as a
>> feedback endpoint (versus having to expose another EP, such as in the
>> case of explicit feedback).  For example, if we are enabling the
>> playback path (and the device does have a capture data ep) then the data
>> ep used for the capture path can be used.
> 
> That's right, so all the plumbing is enabled for the capture path...
> Making a decision to discard the data is very odd, all the work has
> already been done at lower levels, so why not expose the captured data?
> 

So that would be at the USB level, but from the audio DSP end, there are 
still things that need to be enabled to route the data properly.  For 
feedback endpoints, the data we're actually sending won't involve the 
audio streaming side of things on the DSP.

Thanks
Wesley Cheng