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: <dea77277-6971-fe27-1ae0-ed551e84b6e4@linux.intel.com>
Date:   Thu, 26 Jan 2023 09:38:57 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Wesley Cheng <quic_wcheng@...cinc.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



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?