linux-kernel - Re: [RFC PATCH v2 09/22] 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: <5dec443d-9894-2d06-1798-c56b8f2e1e5e@quicinc.com>
Date:   Mon, 30 Jan 2023 14:54:24 -0800
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <lgirdwood@...il.com>, <andersson@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <gregkh@...uxfoundation.org>,
        <Thinh.Nguyen@...opsys.com>, <broonie@...nel.org>,
        <bgoswami@...cinc.com>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <agross@...nel.org>
CC:     <devicetree@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_jackp@...cinc.com>,
        <quic_plai@...cinc.com>
Subject: Re: [RFC PATCH v2 09/22] ASoC: qcom: qdsp6: Introduce USB AFE port to
 q6dsp

Hi Pierre,

On 1/26/2023 7:38 AM, Pierre-Louis Bossart wrote:
> 
> 
> 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?
> 

True, as we discussed before, we only handle the endpoints for the audio 
interface.  Other endpoints, such as HID, or control is still handled by 
the main processor.

> 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.
> 

No worries, I can understand where you're coming from :).  After 
re-reading some of the notations used, I can see where people may be 
confused.

> 
>>   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?
> 

Well, this is a design specific to how the Q6 AFE is implemented.  There 
is a concept for an AFE port to be opened.  However, as mentioned 
earlier, the "port" term used in soc-usb should be more for how many USB 
devices can be supported.

If there was a case the audio DSP would support more than one USB 
device, I believe another AFE port would need to be added.

Thanks
Wesley Cheng