linux-kernel - Re: [PATCH v9 09/34] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fcaa93ba-3ca4-5a18-d3bd-afebe8def327@quicinc.com>
Date:   Wed, 18 Oct 2023 12:36:12 -0700
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
        <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <srinivas.kandagatla@...aro.org>, <bgoswami@...cinc.com>,
        <Thinh.Nguyen@...opsys.com>
CC:     <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v9 09/34] ASoC: qcom: qdsp6: Introduce USB AFE port to
 q6dsp

Hi Pierre,

On 10/18/2023 6:47 AM, 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.

USB2.0 spec, section 5.12.4.3 (Implicit Feedback)
"
Two cases can arise:
• One or more asynchronous sink endpoints are accompanied by an 
asynchronous source endpoint. The
data rate on the source endpoint can be used as implicit feedback 
information to adjust the data rate on
the sink endpoint(s).
• One or more adaptive source endpoints are accompanied by an adaptive 
sink endpoint. The source
endpoint can adjust its data rate based on the data rate received by the 
sink endpoint.
"

The DSP will get this as part of the USB sync endpoint information which 
it will use to enable this EP.

>>>>    +static const struct snd_soc_dai_ops q6usb_ops = {
>>>> +    .probe        = msm_dai_q6_dai_probe,
>>>> +    .prepare    = q6afe_dai_prepare,
>>>> +    .hw_params    = q6usb_hw_params,
>>>
>>> this is rather confusing with two different layers used for hw_params
>>> and prepare? Additional comments or explanations wouldn't hurt.
>>>
>>
>> I thought this was how the ASoC design was.  Each DAI defined for a
>> particular path has it own set of callbacks implemented to bring up any
>> required resources for that entity.  So in this case, it initializes the
>> "cpu" DAI, which is the main component that handles communication with
>> the audio DSP.
> 
> Usually prepare and hw_params rely on the type of DAI callbacks, but
> here you are mixing "q6afe" and "q6usb" which are shown in your Patch0
> diagram as "cpu" and "codec" dais respectively. I don't think it's
> correct to tie the two, it's a clear layering violation IMHO. The codec
> dai .prepare should not invoke something that modifies the state of the
> CPU dai, which should have its own .prepare callback.

OK, I think I know where the misunderstanding is.  The API callback for 
hw_params() that is being registered here exists in q6afe, but with the 
q6usb prefix.  I will fix that in the next rev.

Thanks
Wesley Cheng