| Message ID | 20230308235751.495-1-quic_wcheng@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce QC USB SND audio offloading support | expand |
On Wed, Mar 08, 2023 at 03:57:23PM -0800, Wesley Cheng wrote: > Changes in v3: > - Changed prefix from RFC to PATCH > - Rebased entire series to usb-next > - Updated copyright years This is much better, thanks. I've done some very brief high-level skimming and found minor issues, and one major one. I'll let others review this in more depth right now, as I am way behind in reviewing other USB patches and need to get to them first. thanks, greg k-h
On 3/8/23 17:57, Wesley Cheng wrote: > Changes in v3: > - Changed prefix from RFC to PATCH > - Rebased entire series to usb-next > - Updated copyright years You may want to move the per-version changes after the description of this patchset. > XHCI: > - Rebased changes on top of XHCI changes merged into usb-next, and only added > changes that were still under discussion. > - Added change to read in the "num-hc-interrupters" device property. > > ASoC: > - qusb6 USB backend > - Incorporated suggestions to fetch iommu information with existing APIs > - Added two new sound kcontrols to fetch offload status and offload device > selection. > - offload status - will return the card and pcm device in use > tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0) > > - device selection - set the card and pcm device to enable offload on. Ex.: > tinymix -D 0 set 1 2 0 --> sets offload on card#2 pcm#0 > (this should be the USB card) > > USB SND: > - Fixed up some locking related concerns for registering platform ops. > - Moved callbacks under the register_mutex, so that > - Modified APIs to properly pass more information about the USB SND device, so > that the Q6USB backend can build a device list/map, in order to monitor offload > status and device selection. > > Changes in v2: > > XHCI: > - Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes > in his tree: > https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters > > Adjustments made to Mathias' changes: > - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h. > Moved dependent structures to this file as well. (so clients can parse out > information from "struct xhci_interrupter") > - Added some basic locking when requesting interrupters. > - Fixed up some sanity checks. > - Removed clearing of the ERSTBA during freeing of the interrupter. (pending > issue where SMMU fault occurs if DMA addr returned is 64b - TODO) > > - Clean up pending events in the XHCI secondary interrupter. While testing USB > bus suspend, it was seen that on bus resume, the xHCI HC would run into a command > timeout. > - Added offloading APIs to xHCI to fetch transfer and event ring information. > > ASoC: > - Modified soc-usb to allow for multiple USB port additions. For this to work, > the USB offload driver has to have a reference to the USB backend by adding > a "usb-soc-be" DT entry to the device saved into XHCI sysdev. > - Created separate dt-bindings for defining USB_RX port. > - Increased APR timeout to accommodate the situation where the AFE port start > command could be delayed due to having to issue a USB bus resume while > handling the QMI stream start command. > > USB SND: > - Added a platform ops during usb_audio_suspend(). This allows for the USB > offload driver to halt the audio stream when system enters PM suspend. This > ensures the audio DSP is not issuing transfers on the USB bus. > - Do not override platform ops if they are already populated. > - Introduce a shared status variable between the USB offload and USB SND layers, > to ensure that only one path is active at a time. If the USB bus is occupied, > then userspace is notified that the path is busy. ---> start of the cover letter: > Several Qualcomm based chipsets can support USB audio offloading to a > dedicated audio DSP, which can take over issuing transfers to the USB > host controller. The intention is to reduce the load on the main > processors in the SoC, and allow them to be placed into lower power modes. > There are several parts to this design: > 1. Adding ASoC binding layer > 2. Create a USB backend for Q6DSP clarify what 'backend' means. I would guess you are referring to the ASoC DPCM concept of Back-End, which typically exposes an audio interface controlled by a DSP? If yes, the description should be "Create a Q6DSP ASoC DPCM BackEnd for USB audio playback/record". > 3. Introduce XHCI interrupter support > 4. Create vendor ops for the USB SND driver Add an introduction as to why this would be needed? which 'vendor' are we talking about, is this on the SOC side or the USB device side? > Adding ASoC binding layer: > soc-usb: Intention is to treat a USB port similar to a headphone jack. > The port is always present on the device, but cable/pin status can be > enabled/disabled. Expose mechanisms for USB backend ASoC drivers to > communicate with USB SND. port == backend? Using different words for the same concept is a sure way to lose the reviewers, and not describing different concepts isn't much better. > Create a USB backend for Q6DSP: > q6usb: Basic backend driver that will be responsible for maintaining the What does this mean? Is this a module that registers a set of ASoC DAIs? It's not clear to me what a 'backend driver' means either in a USB or ASoC context. > resources needed to initiate a playback stream using the Q6DSP. Will > be the entity that checks to make sure the connected USB audio device > supports the requested PCM format. If it does not, the PCM open call will > fail, and userpsace ALSA can take action accordingly. If it's an ASoC backend, there is no PCM open call. You're probably referring to the hw_params, not the open/startup anyways. > > Introduce XHCI interrupter support: > XHCI HCD supports multiple interrupters, which allows for events to be routed > to different event rings. This is determined by "Interrupter Target" field > specified in Section "6.4.1.1 Normal TRB" of the XHCI specification. > > Events in the offloading case will be routed to an event ring that is assigned > to the audio DSP. > > Create vendor ops for the USB SND driver: > qc_audio_offload: This particular driver has several components associated > with it: > - QMI stream request handler > - XHCI interrupter and resource management > - audio DSP memory management so how does this 'qc_audio_offload' interface with 'q6usb' described above? how are the roles different or complementary? > When the audio DSP wants to enable a playback stream, the request is first > received by the ASoC platform sound card. Depending on the selected route, > ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI > will send an AFE port start command (with enabling the USB playback path), and > the audio DSP will handle the request accordingly. > > Part of the AFE USB port start handling will have an exchange of control > messages using the QMI protocol. The qc_audio_offload driver will populate the > buffer information: > - Event ring base address > - EP transfer ring base address > > and pass it along to the audio DSP. All endpoint management will now be handed > over to the DSP, and the main processor is not involved in transfers. > > Overall, implementing this feature will still expose separate sound card and PCM > devices for both the platorm card and USB audio device: > 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D > SM8250-MTP-WCD9380-WSA8810-VA-DMIC > 1 [Audio ]: USB-Audio - USB Audio > Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed > > This is to ensure that userspace ALSA entities can decide which route to take > when executing the audio playback. In the above, if card#1 is selected, then > USB audio data will take the legacy path over the USB PCM drivers, etc... I already voiced my concerns about exposing two cards, each with their own set of volume controls with the same device. It would be much better to have an additional offloaded PCM device for card0... But if the consensus is to have two cards, it's still not clear how the routing would be selected. In the case where there are two USB audio devices attached, the offloaded path would only support one of the two. How would userspace know which of the two is selected? And how would userspace know the difference anyways between two physical devices attached to the platform with no offload, and one physical device with one additional offload path? The names you selected can't be used to identify that card1 is the optimized version of card0. Before we review low-level kernel plumbing, it would be good to give a better overview of how userspace applications are supposed to interact with the cards and identify the offloaded path. Testing with tinyplay/tinymix is fine, but that's a developer-level or CI unit test. we've got to see the broader picture of how a sound server would use this USB offload capability.
Hi Pierre, On 3/9/2023 9:13 AM, Pierre-Louis Bossart wrote: > > > On 3/8/23 17:57, Wesley Cheng wrote: >> Changes in v3: >> - Changed prefix from RFC to PATCH >> - Rebased entire series to usb-next >> - Updated copyright years > > You may want to move the per-version changes after the description of > this patchset. > Thanks for reading through this :). Sure, will do that going forward. >> XHCI: >> - Rebased changes on top of XHCI changes merged into usb-next, and only added >> changes that were still under discussion. >> - Added change to read in the "num-hc-interrupters" device property. >> >> ASoC: >> - qusb6 USB backend >> - Incorporated suggestions to fetch iommu information with existing APIs >> - Added two new sound kcontrols to fetch offload status and offload device >> selection. >> - offload status - will return the card and pcm device in use >> tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0) >> >> - device selection - set the card and pcm device to enable offload on. Ex.: >> tinymix -D 0 set 1 2 0 --> sets offload on card#2 pcm#0 >> (this should be the USB card) >> >> USB SND: >> - Fixed up some locking related concerns for registering platform ops. >> - Moved callbacks under the register_mutex, so that >> - Modified APIs to properly pass more information about the USB SND device, so >> that the Q6USB backend can build a device list/map, in order to monitor offload >> status and device selection. >> >> Changes in v2: >> >> XHCI: >> - Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes >> in his tree: >> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters >> >> Adjustments made to Mathias' changes: >> - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h. >> Moved dependent structures to this file as well. (so clients can parse out >> information from "struct xhci_interrupter") >> - Added some basic locking when requesting interrupters. >> - Fixed up some sanity checks. >> - Removed clearing of the ERSTBA during freeing of the interrupter. (pending >> issue where SMMU fault occurs if DMA addr returned is 64b - TODO) >> >> - Clean up pending events in the XHCI secondary interrupter. While testing USB >> bus suspend, it was seen that on bus resume, the xHCI HC would run into a command >> timeout. >> - Added offloading APIs to xHCI to fetch transfer and event ring information. >> >> ASoC: >> - Modified soc-usb to allow for multiple USB port additions. For this to work, >> the USB offload driver has to have a reference to the USB backend by adding >> a "usb-soc-be" DT entry to the device saved into XHCI sysdev. >> - Created separate dt-bindings for defining USB_RX port. >> - Increased APR timeout to accommodate the situation where the AFE port start >> command could be delayed due to having to issue a USB bus resume while >> handling the QMI stream start command. >> >> USB SND: >> - Added a platform ops during usb_audio_suspend(). This allows for the USB >> offload driver to halt the audio stream when system enters PM suspend. This >> ensures the audio DSP is not issuing transfers on the USB bus. >> - Do not override platform ops if they are already populated. >> - Introduce a shared status variable between the USB offload and USB SND layers, >> to ensure that only one path is active at a time. If the USB bus is occupied, >> then userspace is notified that the path is busy. > > > ---> start of the cover letter: > >> Several Qualcomm based chipsets can support USB audio offloading to a >> dedicated audio DSP, which can take over issuing transfers to the USB >> host controller. The intention is to reduce the load on the main >> processors in the SoC, and allow them to be placed into lower power modes. >> There are several parts to this design: >> 1. Adding ASoC binding layer >> 2. Create a USB backend for Q6DSP > > clarify what 'backend' means. I would guess you are referring to the > ASoC DPCM concept of Back-End, which typically exposes an audio > interface controlled by a DSP? > > If yes, the description should be > > "Create a Q6DSP ASoC DPCM BackEnd for USB audio playback/record". > You're correct. "backend" was referring to a Q6DSP ASoC DPCM backend. >> 3. Introduce XHCI interrupter support >> 4. Create vendor ops for the USB SND driver > > Add an introduction as to why this would be needed? which 'vendor' are > we talking about, is this on the SOC side or the USB device side? > This would be referring to the SoC side. For example, QCOM can potentially have a different implementation of offloading USB SND to the audio DSP versus another OEM. This is to allow those other entities to be able to define their own offload methodology. For the most part, the common operations across all offloading implementations have so far is being able to handle USB SND connect/disconnect events. >> Adding ASoC binding layer: >> soc-usb: Intention is to treat a USB port similar to a headphone jack. >> The port is always present on the device, but cable/pin status can be >> enabled/disabled. Expose mechanisms for USB backend ASoC drivers to >> communicate with USB SND. > > port == backend? > > Using different words for the same concept is a sure way to lose the > reviewers, and not describing different concepts isn't much better. > Yes, port is corresponding to the >> Create a USB backend for Q6DSP: >> q6usb: Basic backend driver that will be responsible for maintaining the > > What does this mean? Is this a module that registers a set of ASoC DAIs? > > It's not clear to me what a 'backend driver' means either in a USB or > ASoC context. > Will fix this up next time. It refers to a Q6DSP DPCM ASoC backend, as you mentioned above. >> resources needed to initiate a playback stream using the Q6DSP. Will >> be the entity that checks to make sure the connected USB audio device >> supports the requested PCM format. If it does not, the PCM open call will >> fail, and userpsace ALSA can take action accordingly. > > If it's an ASoC backend, there is no PCM open call. You're probably > referring to the hw_params, not the open/startup anyways. > Correct. Will fix this. >> >> Introduce XHCI interrupter support: >> XHCI HCD supports multiple interrupters, which allows for events to be routed >> to different event rings. This is determined by "Interrupter Target" field >> specified in Section "6.4.1.1 Normal TRB" of the XHCI specification. >> >> Events in the offloading case will be routed to an event ring that is assigned >> to the audio DSP. >> >> Create vendor ops for the USB SND driver: >> qc_audio_offload: This particular driver has several components associated >> with it: >> - QMI stream request handler >> - XHCI interrupter and resource management >> - audio DSP memory management > > so how does this 'qc_audio_offload' interface with 'q6usb' described > above? how are the roles different or complementary? > So in general you can think that the qc_audio_offload is a complement to the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC framework doesn't have any communication with USB SND, the ASoC DPCM USB backend (q6usb) will have to be the entity that maintains what is going on in USB SND. That way, sessions initiated through the ASoC managed sound card can evaluate what is available based on information reported by q6usb. qc_audio_offload and q6usb will have some interaction between each other. The majority of communication between qc_audio_offload and q6usb is reporting the device connection events. >> When the audio DSP wants to enable a playback stream, the request is first >> received by the ASoC platform sound card. Depending on the selected route, >> ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI >> will send an AFE port start command (with enabling the USB playback path), and >> the audio DSP will handle the request accordingly. >> >> Part of the AFE USB port start handling will have an exchange of control >> messages using the QMI protocol. The qc_audio_offload driver will populate the >> buffer information: >> - Event ring base address >> - EP transfer ring base address >> >> and pass it along to the audio DSP. All endpoint management will now be handed >> over to the DSP, and the main processor is not involved in transfers. >> >> Overall, implementing this feature will still expose separate sound card and PCM >> devices for both the platorm card and USB audio device: >> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >> 1 [Audio ]: USB-Audio - USB Audio >> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed >> >> This is to ensure that userspace ALSA entities can decide which route to take >> when executing the audio playback. In the above, if card#1 is selected, then >> USB audio data will take the legacy path over the USB PCM drivers, etc... > > I already voiced my concerns about exposing two cards, each with their > own set of volume controls with the same device. It would be much better > to have an additional offloaded PCM device for card0... > > But if the consensus is to have two cards, it's still not clear how the > routing would be selected. In the case where there are two USB audio > devices attached, the offloaded path would only support one of the two. > How would userspace know which of the two is selected? > With patch#24: https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u Now, userspace can at least choose which device it wants to offload. Part of doing that would mean userspace knows what USB SND card devices are available, so it is aware of which devices are shared (between the offload and USB SND path) > And how would userspace know the difference anyways between two physical > devices attached to the platform with no offload, and one physical > device with one additional offload path? The names you selected can't be > used to identify that card1 is the optimized version of card0. > Is userspace currently able to differentiate between cards that are created by USB SND versus ASoC? How complex can the userspace card discovery be? Can it query kcontrols at this point in time? If so, maybe we can change the names of the newly added ones to reflect that it is an offload device? SND kcontrol names are currently: Q6USB offload status Q6USB offload SND device select > Before we review low-level kernel plumbing, it would be good to give a > better overview of how userspace applications are supposed to interact > with the cards and identify the offloaded path. Testing with > tinyplay/tinymix is fine, but that's a developer-level or CI unit test. > we've got to see the broader picture of how a sound server would use > this USB offload capability. Sure, I think that is fine. I was hoping that at least adding some of the new kcontrols would help userspace make use of this path in general, but we can add more information if required. Thanks Wesley Cheng
>>> Create vendor ops for the USB SND driver: >>> qc_audio_offload: This particular driver has several components >>> associated >>> with it: >>> - QMI stream request handler >>> - XHCI interrupter and resource management >>> - audio DSP memory management >> >> so how does this 'qc_audio_offload' interface with 'q6usb' described >> above? how are the roles different or complementary? >> > So in general you can think that the qc_audio_offload is a complement to > the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC Humm, that is far from clear. I don't get how a something that interacts with the USB class driver can also be in charge of the audio DSP memory management. > framework doesn't have any communication with USB SND, the ASoC DPCM USB > backend (q6usb) will have to be the entity that maintains what is going > on in USB SND. That way, sessions initiated through the ASoC managed > sound card can evaluate what is available based on information reported > by q6usb. > > qc_audio_offload and q6usb will have some interaction between each > other. The majority of communication between qc_audio_offload and q6usb > is reporting the device connection events. It's already complicated to figure out how the DSP and USB class driver might interact and probe/timing dependencies, but with two additional drivers in the mix it's really hard to understand. Maybe ascii-art would help describe the concepts and types of information exchanged. Maintaining a consistent state across multiple drivers is not an easy task. > >>> When the audio DSP wants to enable a playback stream, the request is >>> first >>> received by the ASoC platform sound card. Depending on the selected >>> route, >>> ASoC will bring up the individual DAIs in the path. The Q6USB >>> backend DAI >>> will send an AFE port start command (with enabling the USB playback >>> path), and >>> the audio DSP will handle the request accordingly. >>> >>> Part of the AFE USB port start handling will have an exchange of control >>> messages using the QMI protocol. The qc_audio_offload driver will >>> populate the >>> buffer information: >>> - Event ring base address >>> - EP transfer ring base address >>> >>> and pass it along to the audio DSP. All endpoint management will now >>> be handed >>> over to the DSP, and the main processor is not involved in transfers. >>> >>> Overall, implementing this feature will still expose separate sound >>> card and PCM >>> devices for both the platorm card and USB audio device: >>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>> 1 [Audio ]: USB-Audio - USB Audio >>> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, >>> high speed >>> >>> This is to ensure that userspace ALSA entities can decide which route >>> to take >>> when executing the audio playback. In the above, if card#1 is >>> selected, then >>> USB audio data will take the legacy path over the USB PCM drivers, >>> etc... >> >> I already voiced my concerns about exposing two cards, each with their >> own set of volume controls with the same device. It would be much better >> to have an additional offloaded PCM device for card0... >> >> But if the consensus is to have two cards, it's still not clear how the >> routing would be selected. In the case where there are two USB audio >> devices attached, the offloaded path would only support one of the two. >> How would userspace know which of the two is selected? >> > > With patch#24: > https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u > > Now, userspace can at least choose which device it wants to offload. > Part of doing that would mean userspace knows what USB SND card devices > are available, so it is aware of which devices are shared (between the > offload and USB SND path) > >> And how would userspace know the difference anyways between two physical >> devices attached to the platform with no offload, and one physical >> device with one additional offload path? The names you selected can't be >> used to identify that card1 is the optimized version of card0. >> > > Is userspace currently able to differentiate between cards that are > created by USB SND versus ASoC? How complex can the userspace card > discovery be? Can it query kcontrols at this point in time? If so, > maybe we can change the names of the newly added ones to reflect that it > is an offload device? > > SND kcontrol names are currently: > Q6USB offload status > Q6USB offload SND device select I must admit I've never seen kcontrols being used to identify what the card is, and in this case it's a pretend-card that's just an improved version of another. It might be easier to use something else, such as the component strings. > >> Before we review low-level kernel plumbing, it would be good to give a >> better overview of how userspace applications are supposed to interact >> with the cards and identify the offloaded path. Testing with >> tinyplay/tinymix is fine, but that's a developer-level or CI unit test. >> we've got to see the broader picture of how a sound server would use >> this USB offload capability. > > Sure, I think that is fine. I was hoping that at least adding some of > the new kcontrols would help userspace make use of this path in general, > but we can add more information if required. Can I ask if this solution has been used with a complete userspace stack already? I could see how this might be used with a relatively fixed Android HAL, where the platform and routing are relatively controlled. I don't see how a more generic audio server would deal with the discovery and routing.
Hi Pierre, On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote: > >>>> Create vendor ops for the USB SND driver: >>>> qc_audio_offload: This particular driver has several components >>>> associated >>>> with it: >>>> - QMI stream request handler >>>> - XHCI interrupter and resource management >>>> - audio DSP memory management >>> >>> so how does this 'qc_audio_offload' interface with 'q6usb' described >>> above? how are the roles different or complementary? >>> >> So in general you can think that the qc_audio_offload is a complement to >> the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC > > Humm, that is far from clear. I don't get how a something that interacts > with the USB class driver can also be in charge of the audio DSP memory > management. > This is because the USB class driver is the entity which is going to work with the USB HCD (XHCI) in this case to fetch the required addresses, and map that into memory accessible by the audio DSP. It would be odd to be doing that from the q6usb end, which is part of the ASoC layer. >> framework doesn't have any communication with USB SND, the ASoC DPCM USB >> backend (q6usb) will have to be the entity that maintains what is going >> on in USB SND. That way, sessions initiated through the ASoC managed >> sound card can evaluate what is available based on information reported >> by q6usb. >> >> qc_audio_offload and q6usb will have some interaction between each >> other. The majority of communication between qc_audio_offload and q6usb >> is reporting the device connection events. > > It's already complicated to figure out how the DSP and USB class driver > might interact and probe/timing dependencies, but with two additional > drivers in the mix it's really hard to understand. > I did test some cases based on existence of both these drivers (qc_audio_offload and q6usb). If either one doesn't exist in the system, then the offload path would not work. I did improve some of these potential sequences in the latest revision, such as patch#28. This would address scenarios where the q6usb ASoC DPCM backend wasn't probed, while the USB SND (and qc_audio_offload) were still detecting device connections. Once the Q6USB driver is probed, then the offload snd kcontrols would be created, and devices would be properly identified with the rediscover api. > Maybe ascii-art would help describe the concepts and types of > information exchanged. Maintaining a consistent state across multiple > drivers is not an easy task. > Hopefully this might help? I know its a lot to read through. USB | ASoC -------------------------------------------------------------------- | _________________________ | |sm8250 platform card | | |_________________________| | | | | ___V____ ____V____ | |Q6USB | |Q6AFE | #5 | |"codec" | |"cpu" | | |________| |_________| | ^ | | #6 | ___V____ | |SOC-USB | ________ #1 ________ #7 | | |USB SND |<--->|QC offld|<------------>|________| |(card.c)| | |<---------- ^ |________| |________|___ #4 | | | ^ ^ | | | ___V__________________ | #2 | #2 | | | |APR/GLINK | __ V_______________V_____ | | | |______________________| |USB SND (endpoint.c) | | | | ^ |_________________________| | | | #8 | ^ | | | ___________V___________ | #3 | | |->|audio DSP | ___________V_____________ | | |_______________________| |XHCI HCD |<- | |_________________________| | #1 - USB SND and QC offload: Initialization: - Register platform operations, to receive connect/disconnect events from USB SND. - QC offload creates a QMI handle, in order to receive QMI requests from the audio DSP. Runtime: - USB SND passes along "struct snd_usb_audio" in order for QC offload to reference USB UAC desc parsing/USB SND helper APIs. - USB device disconnection events will result in clearing of the chip entry. #2 - USB SND and QC offload endpoints: Runtime: - In the non-offloaded path, USB snd will utilize functions exposed by USB SND endpoint, to help with fetching USB EP references and queuing URBs. - In the offload path, qc offload will utilize the functions to fetch USB EP references, so that it can use that information to query the XHCI HCD. - Likewise, both will clean up endpoints when audio stream is not in use. #3 - XHCI HCD: Initialization: - During XHCI probe timing, when the USB HCD is added to the system, it will also initialize the secondary event rings. Runtime: - During USB device plug ins/outs, allocates device slot, assigns eps, and initializes transfer rings. #4 - QC offload and XHCI: Runtime: - QC offload needs to reference the transfer ring and secondary event ring addresses by executing XHCI offload management APIs. - This happens when audio DSP receives a USB QMI stream request. #5 - ASoC components: Initialization: - The SM8250 platform sound card driver fetches DT node entries defining the ASoC links. This chain/link has the components involved for a particular Q6AFE path. (not only USB offload) - "cpu" - this is the ASoC CPU DAI that handles interaction with the Q6 DSP's audio protocol. (AFE ports) - "codec" - the ASoC codec (backend) DAI defined - Registers ASoC platform sound card based on links defined in the DT node. - Probes DAI components involved, ie Q6USB and Q6AFE Runtime: - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio session, such as issuing AFE port start commands (part of the protocol used to communicate the audio session info) - Q6USB will be there to now check for if format requested is supported by the device, and maintain offloading status. #6 - Q6USB and SOC-USB: Initialization: - Q6USB will query QC offload for USB device connection states. (through soc-usb) - Creates a SOC USB entry, that carries information about resources, such as audio DSP memory information and requested XHCI event ring index. Runtime: - SOC-USB will receive connect/disconnect events and propagate to Q6USB. - Q6USB makes devices available for offloading based on these events. - Sets Q6AFE port configurations to select the USB SND card# and PCM#. #7 - SOC-USB and QC offload: Initialization: - Rediscover USB SND devices when the SOC-USB entry is created (if needed) - For situations where the Q6USB DAI hasn't been probed. Runtime: - Propagate connect/disconnect events. #8 - audio DSP and QC offload: Runtime: - Handle QMI requests coming from audio DSP. These requests come AFTER the Q6AFE port is opened by the Q6AFE DAI(#6) - Returns memory information about resources allocated by XHCI. - Enables audio playback when this QMI transaction is completed. >> >>>> When the audio DSP wants to enable a playback stream, the request is >>>> first >>>> received by the ASoC platform sound card. Depending on the selected >>>> route, >>>> ASoC will bring up the individual DAIs in the path. The Q6USB >>>> backend DAI >>>> will send an AFE port start command (with enabling the USB playback >>>> path), and >>>> the audio DSP will handle the request accordingly. >>>> >>>> Part of the AFE USB port start handling will have an exchange of control >>>> messages using the QMI protocol. The qc_audio_offload driver will >>>> populate the >>>> buffer information: >>>> - Event ring base address >>>> - EP transfer ring base address >>>> >>>> and pass it along to the audio DSP. All endpoint management will now >>>> be handed >>>> over to the DSP, and the main processor is not involved in transfers. >>>> >>>> Overall, implementing this feature will still expose separate sound >>>> card and PCM >>>> devices for both the platorm card and USB audio device: >>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>>> 1 [Audio ]: USB-Audio - USB Audio >>>> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, >>>> high speed >>>> >>>> This is to ensure that userspace ALSA entities can decide which route >>>> to take >>>> when executing the audio playback. In the above, if card#1 is >>>> selected, then >>>> USB audio data will take the legacy path over the USB PCM drivers, >>>> etc... >>> >>> I already voiced my concerns about exposing two cards, each with their >>> own set of volume controls with the same device. It would be much better >>> to have an additional offloaded PCM device for card0... >>> >>> But if the consensus is to have two cards, it's still not clear how the >>> routing would be selected. In the case where there are two USB audio >>> devices attached, the offloaded path would only support one of the two. >>> How would userspace know which of the two is selected? >>> >> >> With patch#24: >> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u >> >> Now, userspace can at least choose which device it wants to offload. >> Part of doing that would mean userspace knows what USB SND card devices >> are available, so it is aware of which devices are shared (between the >> offload and USB SND path) >> >>> And how would userspace know the difference anyways between two physical >>> devices attached to the platform with no offload, and one physical >>> device with one additional offload path? The names you selected can't be >>> used to identify that card1 is the optimized version of card0. >>> >> >> Is userspace currently able to differentiate between cards that are >> created by USB SND versus ASoC? How complex can the userspace card >> discovery be? Can it query kcontrols at this point in time? If so, >> maybe we can change the names of the newly added ones to reflect that it >> is an offload device? >> >> SND kcontrol names are currently: >> Q6USB offload status >> Q6USB offload SND device select > > I must admit I've never seen kcontrols being used to identify what the > card is, and in this case it's a pretend-card that's just an improved > version of another. It might be easier to use something else, such as > the component strings. Its not exactly a pretend card, right? This is part of the overall platform sound card we have in the system. At the moment, I'm only testing by adding the USB audio routing, but there can be several ASoC links defined in the overall platform card. The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle. USB is only one of those. >> >>> Before we review low-level kernel plumbing, it would be good to give a >>> better overview of how userspace applications are supposed to interact >>> with the cards and identify the offloaded path. Testing with >>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test. >>> we've got to see the broader picture of how a sound server would use >>> this USB offload capability. >> >> Sure, I think that is fine. I was hoping that at least adding some of >> the new kcontrols would help userspace make use of this path in general, >> but we can add more information if required. > > Can I ask if this solution has been used with a complete userspace stack > already? I could see how this might be used with a relatively fixed Its been used only with the Android HAL. > Android HAL, where the platform and routing are relatively controlled. I > don't see how a more generic audio server would deal with the discovery > and routing. > This is why your input is helpful, since it provides another use case that wasn't considered. I think in our previous discussions the tagging possibility was a good idea, and was hoping that it could help. Could tag all USB SND cards to the platform sound card as well, and if the power saving path is chosen, it would issue the playback on the platform sound card. (if not in use) In this case, the offload path wouldn't be the default routing, and only enabled for power optimized path. Thanks Wesley Cheng
On 3/13/23 18:43, Wesley Cheng wrote: > Hi Pierre, > > On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote: >> >>>>> Create vendor ops for the USB SND driver: >>>>> qc_audio_offload: This particular driver has several components >>>>> associated >>>>> with it: >>>>> - QMI stream request handler >>>>> - XHCI interrupter and resource management >>>>> - audio DSP memory management >>>> >>>> so how does this 'qc_audio_offload' interface with 'q6usb' described >>>> above? how are the roles different or complementary? >>>> >>> So in general you can think that the qc_audio_offload is a complement to >>> the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC >> >> Humm, that is far from clear. I don't get how a something that interacts >> with the USB class driver can also be in charge of the audio DSP memory >> management. >> > > This is because the USB class driver is the entity which is going to > work with the USB HCD (XHCI) in this case to fetch the required > addresses, and map that into memory accessible by the audio DSP. It > would be odd to be doing that from the q6usb end, which is part of the > ASoC layer. > >>> framework doesn't have any communication with USB SND, the ASoC DPCM USB >>> backend (q6usb) will have to be the entity that maintains what is going >>> on in USB SND. That way, sessions initiated through the ASoC managed >>> sound card can evaluate what is available based on information reported >>> by q6usb. >>> >>> qc_audio_offload and q6usb will have some interaction between each >>> other. The majority of communication between qc_audio_offload and q6usb >>> is reporting the device connection events. >> >> It's already complicated to figure out how the DSP and USB class driver >> might interact and probe/timing dependencies, but with two additional >> drivers in the mix it's really hard to understand. >> > > I did test some cases based on existence of both these drivers > (qc_audio_offload and q6usb). If either one doesn't exist in the > system, then the offload path would not work. I did improve some of > these potential sequences in the latest revision, such as patch#28. This > would address scenarios where the q6usb ASoC DPCM backend wasn't probed, > while the USB SND (and qc_audio_offload) were still detecting device > connections. > > Once the Q6USB driver is probed, then the offload snd kcontrols would be > created, and devices would be properly identified with the rediscover api. > >> Maybe ascii-art would help describe the concepts and types of >> information exchanged. Maintaining a consistent state across multiple >> drivers is not an easy task. >> > > Hopefully this might help? I know its a lot to read through. It's very helpful! Thanks for spending the time to illustrate the different building blocks. > > USB | ASoC > -------------------------------------------------------------------- > | _________________________ > | |sm8250 platform card | > | |_________________________| > | | | > | ___V____ ____V____ > | |Q6USB | |Q6AFE | #5 > | |"codec" | |"cpu" | > | |________| |_________| > | ^ > | | #6 > | ___V____ > | |SOC-USB | > ________ #1 ________ #7 | | > |USB SND |<--->|QC offld|<------------>|________| > |(card.c)| | |<---------- ^ > |________| |________|___ #4 | | | > ^ ^ | | | ___V__________________ > | #2 | #2 | | | |APR/GLINK | > __ V_______________V_____ | | | |______________________| > |USB SND (endpoint.c) | | | | ^ > |_________________________| | | | #8 | > ^ | | | ___________V___________ > | #3 | | |->|audio DSP | > ___________V_____________ | | |_______________________| > |XHCI HCD |<- | > |_________________________| | > > > #1 - USB SND and QC offload: > Initialization: > - Register platform operations, to receive connect/disconnect events > from USB SND. > - QC offload creates a QMI handle, in order to receive QMI requests > from the audio DSP. > > Runtime: > - USB SND passes along "struct snd_usb_audio" in order for QC offload > to reference USB UAC desc parsing/USB SND helper APIs. > - USB device disconnection events will result in clearing of the chip > entry. > > #2 - USB SND and QC offload endpoints: > Runtime: > - In the non-offloaded path, USB snd will utilize functions exposed by > USB SND endpoint, to help with fetching USB EP references and queuing > URBs. > - In the offload path, qc offload will utilize the functions to fetch > USB EP references, so that it can use that information to query the > XHCI HCD. > - Likewise, both will clean up endpoints when audio stream is not in use. > > #3 - XHCI HCD: > Initialization: > - During XHCI probe timing, when the USB HCD is added to the system, it > will also initialize the secondary event rings. > > Runtime: > - During USB device plug ins/outs, allocates device slot, assigns eps, > and initializes transfer rings. > > #4 - QC offload and XHCI: > Runtime: > - QC offload needs to reference the transfer ring and secondary event ring > addresses by executing XHCI offload management APIs. > - This happens when audio DSP receives a USB QMI stream request. > > #5 - ASoC components: > Initialization: > - The SM8250 platform sound card driver fetches DT node entries defining > the ASoC links. This chain/link has the components involved for a > particular Q6AFE path. (not only USB offload) > - "cpu" - this is the ASoC CPU DAI that handles interaction with the > Q6 DSP's audio protocol. (AFE ports) > - "codec" - the ASoC codec (backend) DAI defined > - Registers ASoC platform sound card based on links defined in the DT node. > - Probes DAI components involved, ie Q6USB and Q6AFE > > Runtime: > - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio > session, such as issuing AFE port start commands (part of the protocol > used to communicate the audio session info) > - Q6USB will be there to now check for if format requested is supported by > the device, and maintain offloading status. > > #6 - Q6USB and SOC-USB: > Initialization: > - Q6USB will query QC offload for USB device connection states. (through > soc-usb) > - Creates a SOC USB entry, that carries information about resources, > such as audio DSP memory information and requested XHCI event ring > index. > > Runtime: > - SOC-USB will receive connect/disconnect events and propagate to Q6USB. > - Q6USB makes devices available for offloading based on these events. > - Sets Q6AFE port configurations to select the USB SND card# and PCM#. > > #7 - SOC-USB and QC offload: > Initialization: > - Rediscover USB SND devices when the SOC-USB entry is created (if needed) > - For situations where the Q6USB DAI hasn't been probed. > > Runtime: > - Propagate connect/disconnect events. Is the SOC-USB module or building blocks intended to be generic or Qualcomm agnostic? It's not clear to me how it would handle "audio DSP memory information and requested XHCI event ring index." In addition, it seems to be the "bridge" or means of communication between qc_audio_offload and q6usb, is this not based on custom events or triggers? Along the same lines, this SOC-USB entity interfaces with APR/GLINK which doesn't speak to me so it must be a QCOM interface? I am trying to see if this design could be used for other architectures, and the QCOM-specific and generic parts are not obvious. > #8 - audio DSP and QC offload: > Runtime: > - Handle QMI requests coming from audio DSP. These requests come AFTER > the Q6AFE port is opened by the Q6AFE DAI(#6) > - Returns memory information about resources allocated by XHCI. > - Enables audio playback when this QMI transaction is completed. > >>> >>>>> When the audio DSP wants to enable a playback stream, the request is >>>>> first >>>>> received by the ASoC platform sound card. Depending on the selected >>>>> route, >>>>> ASoC will bring up the individual DAIs in the path. The Q6USB >>>>> backend DAI >>>>> will send an AFE port start command (with enabling the USB playback >>>>> path), and >>>>> the audio DSP will handle the request accordingly. >>>>> >>>>> Part of the AFE USB port start handling will have an exchange of >>>>> control >>>>> messages using the QMI protocol. The qc_audio_offload driver will >>>>> populate the >>>>> buffer information: >>>>> - Event ring base address >>>>> - EP transfer ring base address >>>>> >>>>> and pass it along to the audio DSP. All endpoint management will now >>>>> be handed >>>>> over to the DSP, and the main processor is not involved in transfers. >>>>> >>>>> Overall, implementing this feature will still expose separate sound >>>>> card and PCM >>>>> devices for both the platorm card and USB audio device: >>>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>>>> 1 [Audio ]: USB-Audio - USB Audio >>>>> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, >>>>> high speed >>>>> >>>>> This is to ensure that userspace ALSA entities can decide which route >>>>> to take >>>>> when executing the audio playback. In the above, if card#1 is >>>>> selected, then >>>>> USB audio data will take the legacy path over the USB PCM drivers, >>>>> etc... >>>> >>>> I already voiced my concerns about exposing two cards, each with their >>>> own set of volume controls with the same device. It would be much >>>> better >>>> to have an additional offloaded PCM device for card0... >>>> >>>> But if the consensus is to have two cards, it's still not clear how the >>>> routing would be selected. In the case where there are two USB audio >>>> devices attached, the offloaded path would only support one of the two. >>>> How would userspace know which of the two is selected? >>>> >>> >>> With patch#24: >>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u >>> >>> Now, userspace can at least choose which device it wants to offload. >>> Part of doing that would mean userspace knows what USB SND card devices >>> are available, so it is aware of which devices are shared (between the >>> offload and USB SND path) >>> >>>> And how would userspace know the difference anyways between two >>>> physical >>>> devices attached to the platform with no offload, and one physical >>>> device with one additional offload path? The names you selected >>>> can't be >>>> used to identify that card1 is the optimized version of card0. >>>> >>> >>> Is userspace currently able to differentiate between cards that are >>> created by USB SND versus ASoC? How complex can the userspace card >>> discovery be? Can it query kcontrols at this point in time? If so, >>> maybe we can change the names of the newly added ones to reflect that it >>> is an offload device? >>> >>> SND kcontrol names are currently: >>> Q6USB offload status >>> Q6USB offload SND device select >> >> I must admit I've never seen kcontrols being used to identify what the >> card is, and in this case it's a pretend-card that's just an improved >> version of another. It might be easier to use something else, such as >> the component strings. > > Its not exactly a pretend card, right? This is part of the overall > platform sound card we have in the system. At the moment, I'm only > testing by adding the USB audio routing, but there can be several ASoC > links defined in the overall platform card. Sorry, I misunderstood the proposal. I thought there would be one card for "generic USB Audio", and another one for "DSP-offloaded USB Audio". I assumed, probably mistakenly, that all local audio endpoints (speaker,mics) would be exposed as a separate card. It looks like it's more "generic USB Audio" and "DSP Audio", with the USB offload being exposed as a PCM device of the latter. Did I get this right? In this case, presumably there can be some sort of UCM file for the "DSP Audio card" that contains the configuration or knows which kcontrols to look for. But my point about detection hold. You could perfectly well have a 'Jack control' that tells userspace when a device is connected. That way there's no guess work, it's similar to HDMI for Intel: the device is exposed but only valid when the jack control is set. > The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle. USB > is only one of those. > >>> >>>> Before we review low-level kernel plumbing, it would be good to give a >>>> better overview of how userspace applications are supposed to interact >>>> with the cards and identify the offloaded path. Testing with >>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test. >>>> we've got to see the broader picture of how a sound server would use >>>> this USB offload capability. >>> >>> Sure, I think that is fine. I was hoping that at least adding some of >>> the new kcontrols would help userspace make use of this path in general, >>> but we can add more information if required. >> >> Can I ask if this solution has been used with a complete userspace stack >> already? I could see how this might be used with a relatively fixed > > Its been used only with the Android HAL. ok, that aligns with what I was thinking. > >> Android HAL, where the platform and routing are relatively controlled. I >> don't see how a more generic audio server would deal with the discovery >> and routing. >> > > This is why your input is helpful, since it provides another use case > that wasn't considered. I think in our previous discussions the tagging > possibility was a good idea, and was hoping that it could help. Could > tag all USB SND cards to the platform sound card as well, and if the > power saving path is chosen, it would issue the playback on the platform > sound card. (if not in use) > > In this case, the offload path wouldn't be the default routing, and only > enabled for power optimized path. > > Thanks > Wesley Cheng
Hi Pierre, On 3/13/2023 5:42 PM, Pierre-Louis Bossart wrote: > > > On 3/13/23 18:43, Wesley Cheng wrote: >> Hi Pierre, >> >> On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote: >>> >>>>>> Create vendor ops for the USB SND driver: >>>>>> qc_audio_offload: This particular driver has several components >>>>>> associated >>>>>> with it: >>>>>> - QMI stream request handler >>>>>> - XHCI interrupter and resource management >>>>>> - audio DSP memory management >>>>> >>>>> so how does this 'qc_audio_offload' interface with 'q6usb' described >>>>> above? how are the roles different or complementary? >>>>> >>>> So in general you can think that the qc_audio_offload is a complement to >>>> the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC >>> >>> Humm, that is far from clear. I don't get how a something that interacts >>> with the USB class driver can also be in charge of the audio DSP memory >>> management. >>> >> >> This is because the USB class driver is the entity which is going to >> work with the USB HCD (XHCI) in this case to fetch the required >> addresses, and map that into memory accessible by the audio DSP. It >> would be odd to be doing that from the q6usb end, which is part of the >> ASoC layer. >> >>>> framework doesn't have any communication with USB SND, the ASoC DPCM USB >>>> backend (q6usb) will have to be the entity that maintains what is going >>>> on in USB SND. That way, sessions initiated through the ASoC managed >>>> sound card can evaluate what is available based on information reported >>>> by q6usb. >>>> >>>> qc_audio_offload and q6usb will have some interaction between each >>>> other. The majority of communication between qc_audio_offload and q6usb >>>> is reporting the device connection events. >>> >>> It's already complicated to figure out how the DSP and USB class driver >>> might interact and probe/timing dependencies, but with two additional >>> drivers in the mix it's really hard to understand. >>> >> >> I did test some cases based on existence of both these drivers >> (qc_audio_offload and q6usb). If either one doesn't exist in the >> system, then the offload path would not work. I did improve some of >> these potential sequences in the latest revision, such as patch#28. This >> would address scenarios where the q6usb ASoC DPCM backend wasn't probed, >> while the USB SND (and qc_audio_offload) were still detecting device >> connections. >> >> Once the Q6USB driver is probed, then the offload snd kcontrols would be >> created, and devices would be properly identified with the rediscover api. >> >>> Maybe ascii-art would help describe the concepts and types of >>> information exchanged. Maintaining a consistent state across multiple >>> drivers is not an easy task. >>> >> >> Hopefully this might help? I know its a lot to read through. > > It's very helpful! Thanks for spending the time to illustrate the > different building blocks. > >> >> USB | ASoC >> -------------------------------------------------------------------- >> | _________________________ >> | |sm8250 platform card | >> | |_________________________| >> | | | >> | ___V____ ____V____ >> | |Q6USB | |Q6AFE | #5 >> | |"codec" | |"cpu" | >> | |________| |_________| >> | ^ >> | | #6 >> | ___V____ >> | |SOC-USB | >> ________ #1 ________ #7 | | >> |USB SND |<--->|QC offld|<------------>|________| >> |(card.c)| | |<---------- ^ >> |________| |________|___ #4 | | | >> ^ ^ | | | ___V__________________ >> | #2 | #2 | | | |APR/GLINK | >> __ V_______________V_____ | | | |______________________| >> |USB SND (endpoint.c) | | | | ^ >> |_________________________| | | | #8 | >> ^ | | | ___________V___________ >> | #3 | | |->|audio DSP | >> ___________V_____________ | | |_______________________| >> |XHCI HCD |<- | >> |_________________________| | >> >> >> #1 - USB SND and QC offload: >> Initialization: >> - Register platform operations, to receive connect/disconnect events >> from USB SND. >> - QC offload creates a QMI handle, in order to receive QMI requests >> from the audio DSP. >> >> Runtime: >> - USB SND passes along "struct snd_usb_audio" in order for QC offload >> to reference USB UAC desc parsing/USB SND helper APIs. >> - USB device disconnection events will result in clearing of the chip >> entry. >> >> #2 - USB SND and QC offload endpoints: >> Runtime: >> - In the non-offloaded path, USB snd will utilize functions exposed by >> USB SND endpoint, to help with fetching USB EP references and queuing >> URBs. >> - In the offload path, qc offload will utilize the functions to fetch >> USB EP references, so that it can use that information to query the >> XHCI HCD. >> - Likewise, both will clean up endpoints when audio stream is not in use. >> >> #3 - XHCI HCD: >> Initialization: >> - During XHCI probe timing, when the USB HCD is added to the system, it >> will also initialize the secondary event rings. >> >> Runtime: >> - During USB device plug ins/outs, allocates device slot, assigns eps, >> and initializes transfer rings. >> >> #4 - QC offload and XHCI: >> Runtime: >> - QC offload needs to reference the transfer ring and secondary event ring >> addresses by executing XHCI offload management APIs. >> - This happens when audio DSP receives a USB QMI stream request. >> >> #5 - ASoC components: >> Initialization: >> - The SM8250 platform sound card driver fetches DT node entries defining >> the ASoC links. This chain/link has the components involved for a >> particular Q6AFE path. (not only USB offload) >> - "cpu" - this is the ASoC CPU DAI that handles interaction with the >> Q6 DSP's audio protocol. (AFE ports) >> - "codec" - the ASoC codec (backend) DAI defined >> - Registers ASoC platform sound card based on links defined in the DT node. >> - Probes DAI components involved, ie Q6USB and Q6AFE >> >> Runtime: >> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio >> session, such as issuing AFE port start commands (part of the protocol >> used to communicate the audio session info) >> - Q6USB will be there to now check for if format requested is supported by >> the device, and maintain offloading status. >> >> #6 - Q6USB and SOC-USB: >> Initialization: >> - Q6USB will query QC offload for USB device connection states. (through >> soc-usb) >> - Creates a SOC USB entry, that carries information about resources, >> such as audio DSP memory information and requested XHCI event ring >> index. >> >> Runtime: >> - SOC-USB will receive connect/disconnect events and propagate to Q6USB. >> - Q6USB makes devices available for offloading based on these events. >> - Sets Q6AFE port configurations to select the USB SND card# and PCM#. >> >> #7 - SOC-USB and QC offload: >> Initialization: >> - Rediscover USB SND devices when the SOC-USB entry is created (if needed) >> - For situations where the Q6USB DAI hasn't been probed. >> >> Runtime: >> - Propagate connect/disconnect events. > > Is the SOC-USB module or building blocks intended to be generic or > Qualcomm agnostic? > This should be generic. > It's not clear to me how it would handle "audio DSP memory information > and requested XHCI event ring index." > Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb) will be able to hold "private data" that, in QC case, is defined as: struct q6usb_offload This is passed within the snd_soc_usb_add_port() call: snd_soc_usb_add_port(component->dev, &data->priv, q6usb_alsa_connection_cb); So depending on the user, the private data can contain their own struct with the information they require. > In addition, it seems to be the "bridge" or means of communication > between qc_audio_offload and q6usb, is this not based on custom events > or triggers? > Ideally, no, it shouldn't be based on custom events. Intention for the connect_cb() that is defined is just to receive USB device discovery events from USB SND. From the qc_audio_offload, we call snd_soc_usb_connect() within our platform op that we register to USB SND. //Platform connect_cb() - called from USB SND probe (device connected) static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip) { ... snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number, chip->index, chip->pcm_devs); In the QC situation, we used this to build a list of active devices connected. > Along the same lines, this SOC-USB entity interfaces with APR/GLINK > which doesn't speak to me so it must be a QCOM interface? > Sorry for not labeling those in the diagram, but yes, those are QC specific interfaces. You can just think of it as a type of IPC transport. > I am trying to see if this design could be used for other architectures, > and the QCOM-specific and generic parts are not obvious. > >> #8 - audio DSP and QC offload: >> Runtime: >> - Handle QMI requests coming from audio DSP. These requests come AFTER >> the Q6AFE port is opened by the Q6AFE DAI(#6) >> - Returns memory information about resources allocated by XHCI. >> - Enables audio playback when this QMI transaction is completed. >> >>>> >>>>>> When the audio DSP wants to enable a playback stream, the request is >>>>>> first >>>>>> received by the ASoC platform sound card. Depending on the selected >>>>>> route, >>>>>> ASoC will bring up the individual DAIs in the path. The Q6USB >>>>>> backend DAI >>>>>> will send an AFE port start command (with enabling the USB playback >>>>>> path), and >>>>>> the audio DSP will handle the request accordingly. >>>>>> >>>>>> Part of the AFE USB port start handling will have an exchange of >>>>>> control >>>>>> messages using the QMI protocol. The qc_audio_offload driver will >>>>>> populate the >>>>>> buffer information: >>>>>> - Event ring base address >>>>>> - EP transfer ring base address >>>>>> >>>>>> and pass it along to the audio DSP. All endpoint management will now >>>>>> be handed >>>>>> over to the DSP, and the main processor is not involved in transfers. >>>>>> >>>>>> Overall, implementing this feature will still expose separate sound >>>>>> card and PCM >>>>>> devices for both the platorm card and USB audio device: >>>>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>>>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>>>>> 1 [Audio ]: USB-Audio - USB Audio >>>>>> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, >>>>>> high speed >>>>>> >>>>>> This is to ensure that userspace ALSA entities can decide which route >>>>>> to take >>>>>> when executing the audio playback. In the above, if card#1 is >>>>>> selected, then >>>>>> USB audio data will take the legacy path over the USB PCM drivers, >>>>>> etc... >>>>> >>>>> I already voiced my concerns about exposing two cards, each with their >>>>> own set of volume controls with the same device. It would be much >>>>> better >>>>> to have an additional offloaded PCM device for card0... >>>>> >>>>> But if the consensus is to have two cards, it's still not clear how the >>>>> routing would be selected. In the case where there are two USB audio >>>>> devices attached, the offloaded path would only support one of the two. >>>>> How would userspace know which of the two is selected? >>>>> >>>> >>>> With patch#24: >>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u >>>> >>>> Now, userspace can at least choose which device it wants to offload. >>>> Part of doing that would mean userspace knows what USB SND card devices >>>> are available, so it is aware of which devices are shared (between the >>>> offload and USB SND path) >>>> >>>>> And how would userspace know the difference anyways between two >>>>> physical >>>>> devices attached to the platform with no offload, and one physical >>>>> device with one additional offload path? The names you selected >>>>> can't be >>>>> used to identify that card1 is the optimized version of card0. >>>>> >>>> >>>> Is userspace currently able to differentiate between cards that are >>>> created by USB SND versus ASoC? How complex can the userspace card >>>> discovery be? Can it query kcontrols at this point in time? If so, >>>> maybe we can change the names of the newly added ones to reflect that it >>>> is an offload device? >>>> >>>> SND kcontrol names are currently: >>>> Q6USB offload status >>>> Q6USB offload SND device select >>> >>> I must admit I've never seen kcontrols being used to identify what the >>> card is, and in this case it's a pretend-card that's just an improved >>> version of another. It might be easier to use something else, such as >>> the component strings. >> >> Its not exactly a pretend card, right? This is part of the overall >> platform sound card we have in the system. At the moment, I'm only >> testing by adding the USB audio routing, but there can be several ASoC >> links defined in the overall platform card. > > Sorry, I misunderstood the proposal. I thought there would be one card > for "generic USB Audio", and another one for "DSP-offloaded USB Audio". > I assumed, probably mistakenly, that all local audio endpoints > (speaker,mics) would be exposed as a separate card. > Ah got it. No, that isn't the case here. > It looks like it's more "generic USB Audio" and "DSP Audio", with the > USB offload being exposed as a PCM device of the latter. > > Did I get this right? In this case, presumably there can be some sort of Yep that's correct! > UCM file for the "DSP Audio card" that contains the configuration or > knows which kcontrols to look for. But my point about detection hold. > You could perfectly well have a 'Jack control' that tells userspace when > a device is connected. That way there's no guess work, it's similar to > HDMI for Intel: the device is exposed but only valid when the jack > control is set. > Hmm, ok. Let me see if I can switch up some things. Maybe replace the current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and replace that with a snd jack report. (the snd jack implementation already takes care of updating the pin if needed) Thanks Wesley Cheng >> The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle. USB >> is only one of those. >> >>>> >>>>> Before we review low-level kernel plumbing, it would be good to give a >>>>> better overview of how userspace applications are supposed to interact >>>>> with the cards and identify the offloaded path. Testing with >>>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test. >>>>> we've got to see the broader picture of how a sound server would use >>>>> this USB offload capability. >>>> >>>> Sure, I think that is fine. I was hoping that at least adding some of >>>> the new kcontrols would help userspace make use of this path in general, >>>> but we can add more information if required. >>> >>> Can I ask if this solution has been used with a complete userspace stack >>> already? I could see how this might be used with a relatively fixed >> >> Its been used only with the Android HAL. > > ok, that aligns with what I was thinking. > >> >>> Android HAL, where the platform and routing are relatively controlled. I >>> don't see how a more generic audio server would deal with the discovery >>> and routing. >>> >> >> This is why your input is helpful, since it provides another use case >> that wasn't considered. I think in our previous discussions the tagging >> possibility was a good idea, and was hoping that it could help. Could >> tag all USB SND cards to the platform sound card as well, and if the >> power saving path is chosen, it would issue the playback on the platform >> sound card. (if not in use) >> >> In this case, the offload path wouldn't be the default routing, and only >> enabled for power optimized path. >> >> Thanks >> Wesley Cheng
<snip> >> >>> >>> USB | ASoC >>> -------------------------------------------------------------------- >>> | _________________________ >>> | |sm8250 platform card | >>> | |_________________________| >>> | | | >>> | ___V____ ____V____ >>> | |Q6USB | |Q6AFE | #5 >>> | |"codec" | |"cpu" | >>> | |________| |_________| >>> | ^ >>> | | #6 >>> | ___V____ >>> | |SOC-USB | >>> ________ #1 ________ #7 | | >>> |USB SND |<--->|QC offld|<------------>|________| >>> |(card.c)| | |<---------- ^ >>> |________| |________|___ #4 | | | >>> ^ ^ | | | ___V__________________ >>> | #2 | #2 | | | |APR/GLINK | >>> __ V_______________V_____ | | | |______________________| >>> |USB SND (endpoint.c) | | | | ^ >>> |_________________________| | | | #8 | >>> ^ | | | ___________V___________ >>> | #3 | | |->|audio DSP | >>> ___________V_____________ | | |_______________________| >>> |XHCI HCD |<- | >>> |_________________________| | >>> >>> >>> #1 - USB SND and QC offload: >>> Initialization: >>> - Register platform operations, to receive connect/disconnect events >>> from USB SND. >>> - QC offload creates a QMI handle, in order to receive QMI requests >>> from the audio DSP. >>> >>> Runtime: >>> - USB SND passes along "struct snd_usb_audio" in order for QC offload >>> to reference USB UAC desc parsing/USB SND helper APIs. >>> - USB device disconnection events will result in clearing of the chip >>> entry. >>> >>> #2 - USB SND and QC offload endpoints: >>> Runtime: >>> - In the non-offloaded path, USB snd will utilize functions exposed by >>> USB SND endpoint, to help with fetching USB EP references and queuing >>> URBs. >>> - In the offload path, qc offload will utilize the functions to fetch >>> USB EP references, so that it can use that information to query the >>> XHCI HCD. >>> - Likewise, both will clean up endpoints when audio stream is not in >>> use. >>> >>> #3 - XHCI HCD: >>> Initialization: >>> - During XHCI probe timing, when the USB HCD is added to the system, it >>> will also initialize the secondary event rings. >>> >>> Runtime: >>> - During USB device plug ins/outs, allocates device slot, assigns eps, >>> and initializes transfer rings. >>> >>> #4 - QC offload and XHCI: >>> Runtime: >>> - QC offload needs to reference the transfer ring and secondary event >>> ring >>> addresses by executing XHCI offload management APIs. >>> - This happens when audio DSP receives a USB QMI stream request. >>> >>> #5 - ASoC components: >>> Initialization: >>> - The SM8250 platform sound card driver fetches DT node entries defining >>> the ASoC links. This chain/link has the components involved for a >>> particular Q6AFE path. (not only USB offload) >>> - "cpu" - this is the ASoC CPU DAI that handles interaction with >>> the >>> Q6 DSP's audio protocol. (AFE ports) >>> - "codec" - the ASoC codec (backend) DAI defined >>> - Registers ASoC platform sound card based on links defined in the DT >>> node. >>> - Probes DAI components involved, ie Q6USB and Q6AFE >>> >>> Runtime: >>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an >>> audio >>> session, such as issuing AFE port start commands (part of the >>> protocol >>> used to communicate the audio session info) >>> - Q6USB will be there to now check for if format requested is >>> supported by >>> the device, and maintain offloading status. >>> >>> #6 - Q6USB and SOC-USB: >>> Initialization: >>> - Q6USB will query QC offload for USB device connection states. (through >>> soc-usb) >>> - Creates a SOC USB entry, that carries information about resources, >>> such as audio DSP memory information and requested XHCI event ring >>> index. >>> >>> Runtime: >>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB. >>> - Q6USB makes devices available for offloading based on these events. >>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#. >>> >>> #7 - SOC-USB and QC offload: >>> Initialization: >>> - Rediscover USB SND devices when the SOC-USB entry is created (if >>> needed) >>> - For situations where the Q6USB DAI hasn't been probed. >>> >>> Runtime: >>> - Propagate connect/disconnect events. >> >> Is the SOC-USB module or building blocks intended to be generic or >> Qualcomm agnostic? >> > > This should be generic. ok, but then how would it communicate with APR/GLINK described below [1] > >> It's not clear to me how it would handle "audio DSP memory information >> and requested XHCI event ring index." >> > > Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb) > will be able to hold "private data" that, in QC case, is defined as: > struct q6usb_offload > > This is passed within the snd_soc_usb_add_port() call: > snd_soc_usb_add_port(component->dev, &data->priv, > q6usb_alsa_connection_cb); > > So depending on the user, the private data can contain their own struct > with the information they require. ok, so "handle private data such as audio DSP memory information >> and requested XHCI event ring index" is what you meant. That'd fine. >> In addition, it seems to be the "bridge" or means of communication >> between qc_audio_offload and q6usb, is this not based on custom events >> or triggers? >> > > Ideally, no, it shouldn't be based on custom events. Intention for the > connect_cb() that is defined is just to receive USB device discovery > events from USB SND. From the qc_audio_offload, we call > snd_soc_usb_connect() within our platform op that we register to USB SND. > > //Platform connect_cb() - called from USB SND probe (device connected) > static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip) > { > ... > snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number, > chip->index, chip->pcm_devs); > > In the QC situation, we used this to build a list of active devices > connected. > >> Along the same lines, this SOC-USB entity interfaces with APR/GLINK >> which doesn't speak to me so it must be a QCOM interface?>> > > Sorry for not labeling those in the diagram, but yes, those are QC > specific interfaces. You can just think of it as a type of IPC transport. [1] ... something's not clear on how a generic 'soc-usb' component can directly talk to a vendor-specific IPC. Is there a missing layer? >> I am trying to see if this design could be used for other architectures, >> and the QCOM-specific and generic parts are not obvious. >> >>> #8 - audio DSP and QC offload: >>> Runtime: >>> - Handle QMI requests coming from audio DSP. These requests come AFTER >>> the Q6AFE port is opened by the Q6AFE DAI(#6) >>> - Returns memory information about resources allocated by XHCI. >>> - Enables audio playback when this QMI transaction is completed. >>> >>>>> >>>>>>> When the audio DSP wants to enable a playback stream, the request is >>>>>>> first >>>>>>> received by the ASoC platform sound card. Depending on the selected >>>>>>> route, >>>>>>> ASoC will bring up the individual DAIs in the path. The Q6USB >>>>>>> backend DAI >>>>>>> will send an AFE port start command (with enabling the USB playback >>>>>>> path), and >>>>>>> the audio DSP will handle the request accordingly. >>>>>>> >>>>>>> Part of the AFE USB port start handling will have an exchange of >>>>>>> control >>>>>>> messages using the QMI protocol. The qc_audio_offload driver will >>>>>>> populate the >>>>>>> buffer information: >>>>>>> - Event ring base address >>>>>>> - EP transfer ring base address >>>>>>> >>>>>>> and pass it along to the audio DSP. All endpoint management will >>>>>>> now >>>>>>> be handed >>>>>>> over to the DSP, and the main processor is not involved in >>>>>>> transfers. >>>>>>> >>>>>>> Overall, implementing this feature will still expose separate sound >>>>>>> card and PCM >>>>>>> devices for both the platorm card and USB audio device: >>>>>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>>>>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>>>>>> 1 [Audio ]: USB-Audio - USB Audio >>>>>>> Generic USB Audio at >>>>>>> usb-xhci-hcd.1.auto-1.4, >>>>>>> high speed >>>>>>> >>>>>>> This is to ensure that userspace ALSA entities can decide which >>>>>>> route >>>>>>> to take >>>>>>> when executing the audio playback. In the above, if card#1 is >>>>>>> selected, then >>>>>>> USB audio data will take the legacy path over the USB PCM drivers, >>>>>>> etc... >>>>>> >>>>>> I already voiced my concerns about exposing two cards, each with >>>>>> their >>>>>> own set of volume controls with the same device. It would be much >>>>>> better >>>>>> to have an additional offloaded PCM device for card0... >>>>>> >>>>>> But if the consensus is to have two cards, it's still not clear >>>>>> how the >>>>>> routing would be selected. In the case where there are two USB audio >>>>>> devices attached, the offloaded path would only support one of the >>>>>> two. >>>>>> How would userspace know which of the two is selected? >>>>>> >>>>> >>>>> With patch#24: >>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u >>>>> >>>>> Now, userspace can at least choose which device it wants to offload. >>>>> Part of doing that would mean userspace knows what USB SND card >>>>> devices >>>>> are available, so it is aware of which devices are shared (between the >>>>> offload and USB SND path) >>>>> >>>>>> And how would userspace know the difference anyways between two >>>>>> physical >>>>>> devices attached to the platform with no offload, and one physical >>>>>> device with one additional offload path? The names you selected >>>>>> can't be >>>>>> used to identify that card1 is the optimized version of card0. >>>>>> >>>>> >>>>> Is userspace currently able to differentiate between cards that are >>>>> created by USB SND versus ASoC? How complex can the userspace card >>>>> discovery be? Can it query kcontrols at this point in time? If so, >>>>> maybe we can change the names of the newly added ones to reflect >>>>> that it >>>>> is an offload device? >>>>> >>>>> SND kcontrol names are currently: >>>>> Q6USB offload status >>>>> Q6USB offload SND device select >>>> >>>> I must admit I've never seen kcontrols being used to identify what the >>>> card is, and in this case it's a pretend-card that's just an improved >>>> version of another. It might be easier to use something else, such as >>>> the component strings. >>> >>> Its not exactly a pretend card, right? This is part of the overall >>> platform sound card we have in the system. At the moment, I'm only >>> testing by adding the USB audio routing, but there can be several ASoC >>> links defined in the overall platform card. >> >> Sorry, I misunderstood the proposal. I thought there would be one card >> for "generic USB Audio", and another one for "DSP-offloaded USB Audio". >> I assumed, probably mistakenly, that all local audio endpoints >> (speaker,mics) would be exposed as a separate card. >> > > Ah got it. No, that isn't the case here. > >> It looks like it's more "generic USB Audio" and "DSP Audio", with the >> USB offload being exposed as a PCM device of the latter. >> >> Did I get this right? In this case, presumably there can be some sort of > > Yep that's correct! ok, that's good. My initial thought was to add a 'DSP offload' PCM to the USB card, you added a "USB offload" PCM to the DSP card. Nice logical swap! Your proposal might be easier in practice since there's typically a vendor-specific configuration file (UCM or custom) file for the DSP, where USB information can be added. It's more problematic to change a generic USB card as we know it today and bolt vendor-specific DSP information on top. The only open I have with your option is that there are still two control paths to e.g. set the volume. It would be so much easier for userspace if there was a single volume control no matter what path is used for data, or make sure the kcontrols are 'mirrored' somehow. If we found a way to address this issue that would be ideal. >> UCM file for the "DSP Audio card" that contains the configuration or >> knows which kcontrols to look for. But my point about detection hold. >> You could perfectly well have a 'Jack control' that tells userspace when >> a device is connected. That way there's no guess work, it's similar to >> HDMI for Intel: the device is exposed but only valid when the jack >> control is set. >> > > Hmm, ok. Let me see if I can switch up some things. Maybe replace the > current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and > replace that with a snd jack report. (the snd jack implementation > already takes care of updating the pin if needed) The jack is useful to let userspace know if a PCM device, i.e. a Front-End, can be used. But if you expose a PCM device, nothing prevents an application from trying to open and use it, we recently had such an issue due to a change in PipeWire that tried to open a non-functional HDMI device. So you do need something to bail if the PCM device is mistakenly used. DAPM pin management seems different, it will turn-on/off parts of the graph connected to an endpoint. Userpace will typically not know anything about pin management, it's an in-kernel concept. Not sure if you have to choose, those are two different layers, no?
Hi Pierre, On 3/13/2023 7:22 PM, Pierre-Louis Bossart wrote: > > <snip> > >>> >>>> >>>> USB | ASoC >>>> -------------------------------------------------------------------- >>>> | _________________________ >>>> | |sm8250 platform card | >>>> | |_________________________| >>>> | | | >>>> | ___V____ ____V____ >>>> | |Q6USB | |Q6AFE | #5 >>>> | |"codec" | |"cpu" | >>>> | |________| |_________| >>>> | ^ >>>> | | #6 >>>> | ___V____ >>>> | |SOC-USB | >>>> ________ #1 ________ #7 | | >>>> |USB SND |<--->|QC offld|<------------>|________| >>>> |(card.c)| | |<---------- ^ >>>> |________| |________|___ #4 | | | >>>> ^ ^ | | | ___V__________________ >>>> | #2 | #2 | | | |APR/GLINK | >>>> __ V_______________V_____ | | | |______________________| >>>> |USB SND (endpoint.c) | | | | ^ >>>> |_________________________| | | | #8 | >>>> ^ | | | ___________V___________ >>>> | #3 | | |->|audio DSP | >>>> ___________V_____________ | | |_______________________| >>>> |XHCI HCD |<- | >>>> |_________________________| | >>>> >>>> >>>> #1 - USB SND and QC offload: >>>> Initialization: >>>> - Register platform operations, to receive connect/disconnect events >>>> from USB SND. >>>> - QC offload creates a QMI handle, in order to receive QMI requests >>>> from the audio DSP. >>>> >>>> Runtime: >>>> - USB SND passes along "struct snd_usb_audio" in order for QC offload >>>> to reference USB UAC desc parsing/USB SND helper APIs. >>>> - USB device disconnection events will result in clearing of the chip >>>> entry. >>>> >>>> #2 - USB SND and QC offload endpoints: >>>> Runtime: >>>> - In the non-offloaded path, USB snd will utilize functions exposed by >>>> USB SND endpoint, to help with fetching USB EP references and queuing >>>> URBs. >>>> - In the offload path, qc offload will utilize the functions to fetch >>>> USB EP references, so that it can use that information to query the >>>> XHCI HCD. >>>> - Likewise, both will clean up endpoints when audio stream is not in >>>> use. >>>> >>>> #3 - XHCI HCD: >>>> Initialization: >>>> - During XHCI probe timing, when the USB HCD is added to the system, it >>>> will also initialize the secondary event rings. >>>> >>>> Runtime: >>>> - During USB device plug ins/outs, allocates device slot, assigns eps, >>>> and initializes transfer rings. >>>> >>>> #4 - QC offload and XHCI: >>>> Runtime: >>>> - QC offload needs to reference the transfer ring and secondary event >>>> ring >>>> addresses by executing XHCI offload management APIs. >>>> - This happens when audio DSP receives a USB QMI stream request. >>>> >>>> #5 - ASoC components: >>>> Initialization: >>>> - The SM8250 platform sound card driver fetches DT node entries defining >>>> the ASoC links. This chain/link has the components involved for a >>>> particular Q6AFE path. (not only USB offload) >>>> - "cpu" - this is the ASoC CPU DAI that handles interaction with >>>> the >>>> Q6 DSP's audio protocol. (AFE ports) >>>> - "codec" - the ASoC codec (backend) DAI defined >>>> - Registers ASoC platform sound card based on links defined in the DT >>>> node. >>>> - Probes DAI components involved, ie Q6USB and Q6AFE >>>> >>>> Runtime: >>>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an >>>> audio >>>> session, such as issuing AFE port start commands (part of the >>>> protocol >>>> used to communicate the audio session info) >>>> - Q6USB will be there to now check for if format requested is >>>> supported by >>>> the device, and maintain offloading status. >>>> >>>> #6 - Q6USB and SOC-USB: >>>> Initialization: >>>> - Q6USB will query QC offload for USB device connection states. (through >>>> soc-usb) >>>> - Creates a SOC USB entry, that carries information about resources, >>>> such as audio DSP memory information and requested XHCI event ring >>>> index. >>>> >>>> Runtime: >>>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB. >>>> - Q6USB makes devices available for offloading based on these events. >>>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#. >>>> >>>> #7 - SOC-USB and QC offload: >>>> Initialization: >>>> - Rediscover USB SND devices when the SOC-USB entry is created (if >>>> needed) >>>> - For situations where the Q6USB DAI hasn't been probed. >>>> >>>> Runtime: >>>> - Propagate connect/disconnect events. >>> >>> Is the SOC-USB module or building blocks intended to be generic or >>> Qualcomm agnostic? >>> >> >> This should be generic. > > ok, but then how would it communicate with APR/GLINK described below [1] To make the diagram a bit more compact, I left out our Q6ASM DAI, which is the path that handles the PCM data/buffers. (not really involved in initializing any part of the offload path) Sorry made a mistake on the diagram. There is no connection from SOC-USB to the APR/GLINK. The Q6USB driver will be the one that is going to configure some of the Q6AFE ports along withe the Q6AFE DAI driver. | ASoC ---------------------------------- | _________________________ | |sm8250 platform card | | |_________________________| | | | | ___V____ ____V____ | |Q6USB | |Q6AFE | #5 | |"codec" | |"cpu" | | |________| |_________| | ^ ^ ^ | #6 | |________| | ___V____ | | |SOC-USB | | #7 | | | ----->|________| | --- | | | | | | _____________V________ | | |APR/GLINK | | | |______________________| | | ^ | | #8 | | | ___________V___________ | |->|audio DSP | | |_______________________| | | >> >>> It's not clear to me how it would handle "audio DSP memory information >>> and requested XHCI event ring index." >>> >> >> Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb) >> will be able to hold "private data" that, in QC case, is defined as: >> struct q6usb_offload >> >> This is passed within the snd_soc_usb_add_port() call: >> snd_soc_usb_add_port(component->dev, &data->priv, >> q6usb_alsa_connection_cb); >> >> So depending on the user, the private data can contain their own struct >> with the information they require. > > ok, so "handle private data such as audio DSP memory information >>> and requested XHCI event ring index" is what you meant. That'd fine. > >>> In addition, it seems to be the "bridge" or means of communication >>> between qc_audio_offload and q6usb, is this not based on custom events >>> or triggers? >>> >> >> Ideally, no, it shouldn't be based on custom events. Intention for the >> connect_cb() that is defined is just to receive USB device discovery >> events from USB SND. From the qc_audio_offload, we call >> snd_soc_usb_connect() within our platform op that we register to USB SND. >> >> //Platform connect_cb() - called from USB SND probe (device connected) >> static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip) >> { >> ... >> snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number, >> chip->index, chip->pcm_devs); >> >> In the QC situation, we used this to build a list of active devices >> connected. >> >>> Along the same lines, this SOC-USB entity interfaces with APR/GLINK >>> which doesn't speak to me so it must be a QCOM interface?>> >> >> Sorry for not labeling those in the diagram, but yes, those are QC >> specific interfaces. You can just think of it as a type of IPC transport. > > [1] ... something's not clear on how a generic 'soc-usb' component can > directly talk to a vendor-specific IPC. > > Is there a missing layer? > :) hopefully the updated diagram clarifies this. >>> I am trying to see if this design could be used for other architectures, >>> and the QCOM-specific and generic parts are not obvious. >>> >>>> #8 - audio DSP and QC offload: >>>> Runtime: >>>> - Handle QMI requests coming from audio DSP. These requests come AFTER >>>> the Q6AFE port is opened by the Q6AFE DAI(#6) >>>> - Returns memory information about resources allocated by XHCI. >>>> - Enables audio playback when this QMI transaction is completed. >>>> >>>>>> >>>>>>>> When the audio DSP wants to enable a playback stream, the request is >>>>>>>> first >>>>>>>> received by the ASoC platform sound card. Depending on the selected >>>>>>>> route, >>>>>>>> ASoC will bring up the individual DAIs in the path. The Q6USB >>>>>>>> backend DAI >>>>>>>> will send an AFE port start command (with enabling the USB playback >>>>>>>> path), and >>>>>>>> the audio DSP will handle the request accordingly. >>>>>>>> >>>>>>>> Part of the AFE USB port start handling will have an exchange of >>>>>>>> control >>>>>>>> messages using the QMI protocol. The qc_audio_offload driver will >>>>>>>> populate the >>>>>>>> buffer information: >>>>>>>> - Event ring base address >>>>>>>> - EP transfer ring base address >>>>>>>> >>>>>>>> and pass it along to the audio DSP. All endpoint management will >>>>>>>> now >>>>>>>> be handed >>>>>>>> over to the DSP, and the main processor is not involved in >>>>>>>> transfers. >>>>>>>> >>>>>>>> Overall, implementing this feature will still expose separate sound >>>>>>>> card and PCM >>>>>>>> devices for both the platorm card and USB audio device: >>>>>>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >>>>>>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC >>>>>>>> 1 [Audio ]: USB-Audio - USB Audio >>>>>>>> Generic USB Audio at >>>>>>>> usb-xhci-hcd.1.auto-1.4, >>>>>>>> high speed >>>>>>>> >>>>>>>> This is to ensure that userspace ALSA entities can decide which >>>>>>>> route >>>>>>>> to take >>>>>>>> when executing the audio playback. In the above, if card#1 is >>>>>>>> selected, then >>>>>>>> USB audio data will take the legacy path over the USB PCM drivers, >>>>>>>> etc... >>>>>>> >>>>>>> I already voiced my concerns about exposing two cards, each with >>>>>>> their >>>>>>> own set of volume controls with the same device. It would be much >>>>>>> better >>>>>>> to have an additional offloaded PCM device for card0... >>>>>>> >>>>>>> But if the consensus is to have two cards, it's still not clear >>>>>>> how the >>>>>>> routing would be selected. In the case where there are two USB audio >>>>>>> devices attached, the offloaded path would only support one of the >>>>>>> two. >>>>>>> How would userspace know which of the two is selected? >>>>>>> >>>>>> >>>>>> With patch#24: >>>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u >>>>>> >>>>>> Now, userspace can at least choose which device it wants to offload. >>>>>> Part of doing that would mean userspace knows what USB SND card >>>>>> devices >>>>>> are available, so it is aware of which devices are shared (between the >>>>>> offload and USB SND path) >>>>>> >>>>>>> And how would userspace know the difference anyways between two >>>>>>> physical >>>>>>> devices attached to the platform with no offload, and one physical >>>>>>> device with one additional offload path? The names you selected >>>>>>> can't be >>>>>>> used to identify that card1 is the optimized version of card0. >>>>>>> >>>>>> >>>>>> Is userspace currently able to differentiate between cards that are >>>>>> created by USB SND versus ASoC? How complex can the userspace card >>>>>> discovery be? Can it query kcontrols at this point in time? If so, >>>>>> maybe we can change the names of the newly added ones to reflect >>>>>> that it >>>>>> is an offload device? >>>>>> >>>>>> SND kcontrol names are currently: >>>>>> Q6USB offload status >>>>>> Q6USB offload SND device select >>>>> >>>>> I must admit I've never seen kcontrols being used to identify what the >>>>> card is, and in this case it's a pretend-card that's just an improved >>>>> version of another. It might be easier to use something else, such as >>>>> the component strings. >>>> >>>> Its not exactly a pretend card, right? This is part of the overall >>>> platform sound card we have in the system. At the moment, I'm only >>>> testing by adding the USB audio routing, but there can be several ASoC >>>> links defined in the overall platform card. >>> >>> Sorry, I misunderstood the proposal. I thought there would be one card >>> for "generic USB Audio", and another one for "DSP-offloaded USB Audio". >>> I assumed, probably mistakenly, that all local audio endpoints >>> (speaker,mics) would be exposed as a separate card. >>> >> >> Ah got it. No, that isn't the case here. >> >>> It looks like it's more "generic USB Audio" and "DSP Audio", with the >>> USB offload being exposed as a PCM device of the latter. >>> >>> Did I get this right? In this case, presumably there can be some sort of >> >> Yep that's correct! > > ok, that's good. > > My initial thought was to add a 'DSP offload' PCM to the USB card, you > added a "USB offload" PCM to the DSP card. Nice logical swap! > > Your proposal might be easier in practice since there's typically a > vendor-specific configuration file (UCM or custom) file for the DSP, > where USB information can be added. > > It's more problematic to change a generic USB card as we know it today > and bolt vendor-specific DSP information on top. > > The only open I have with your option is that there are still two > control paths to e.g. set the volume. It would be so much easier for > userspace if there was a single volume control no matter what path is > used for data, or make sure the kcontrols are 'mirrored' somehow. If we > found a way to address this issue that would be ideal. > Got it. Let me look to see if that is something we can address/add. I think the current implementation is that USB SND will expose some mixer controls based on the UAC descriptor parsing. Then when they want to change the volume (for example) it will result in a USB SETUP transaction. So USB SND will eventually be the entity controlling these changes. >>> UCM file for the "DSP Audio card" that contains the configuration or >>> knows which kcontrols to look for. But my point about detection hold. >>> You could perfectly well have a 'Jack control' that tells userspace when >>> a device is connected. That way there's no guess work, it's similar to >>> HDMI for Intel: the device is exposed but only valid when the jack >>> control is set. >>> >> >> Hmm, ok. Let me see if I can switch up some things. Maybe replace the >> current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and >> replace that with a snd jack report. (the snd jack implementation >> already takes care of updating the pin if needed) > > The jack is useful to let userspace know if a PCM device, i.e. a > Front-End, can be used. But if you expose a PCM device, nothing prevents > an application from trying to open and use it, we recently had such an > issue due to a change in PipeWire that tried to open a non-functional > HDMI device. So you do need something to bail if the PCM device is > mistakenly used. > > DAPM pin management seems different, it will turn-on/off parts of the > graph connected to an endpoint. Userpace will typically not know > anything about pin management, it's an in-kernel concept. > > Not sure if you have to choose, those are two different layers, no? Will review this more and fix it in the next rev. Thanks for the inputs! Thanks Wesley Cheng
Hi Wesley, > Sorry made a mistake on the diagram. There is no connection from > SOC-USB to the APR/GLINK. The Q6USB driver will be the one that is > going to configure some of the Q6AFE ports along withe the Q6AFE DAI > driver. > > | ASoC > ---------------------------------- > | _________________________ > | |sm8250 platform card | > | |_________________________| > | | | > | ___V____ ____V____ > | |Q6USB | |Q6AFE | #5 > | |"codec" | |"cpu" | > | |________| |_________| > | ^ ^ ^ > | #6 | |________| > | ___V____ | > | |SOC-USB | | > #7 | | | > ----->|________| | > --- | > | | | > | | _____________V________ > | | |APR/GLINK | > | | |______________________| > | | ^ > | | #8 | > | | ___________V___________ > | |->|audio DSP | > | |_______________________| > | > | > >>> Makes sense now, thank you for the clarification. I'll have to dig more in this 'soc-usb' block, it's clearly a key component that will have to maintain a consistent state across two different parts of the stack and deal with probe/remove/shutdown. >> My initial thought was to add a 'DSP offload' PCM to the USB card, you >> added a "USB offload" PCM to the DSP card. Nice logical swap! >> >> Your proposal might be easier in practice since there's typically a >> vendor-specific configuration file (UCM or custom) file for the DSP, >> where USB information can be added. >> >> It's more problematic to change a generic USB card as we know it today >> and bolt vendor-specific DSP information on top. >> >> The only open I have with your option is that there are still two >> control paths to e.g. set the volume. It would be so much easier for >> userspace if there was a single volume control no matter what path is >> used for data, or make sure the kcontrols are 'mirrored' somehow. If we >> found a way to address this issue that would be ideal. >> > > Got it. Let me look to see if that is something we can address/add. I > think the current implementation is that USB SND will expose some mixer > controls based on the UAC descriptor parsing. Then when they want to > change the volume (for example) it will result in a USB SETUP transaction. > > So USB SND will eventually be the entity controlling these changes. That's probably ok then, am I getting this right that the the DSP card would not expose any USB-related kcontrols then, i.e. the ONLY path to change volumes, etc., would through the regular USB card kcontrols? That would limit the changes in the platform sound card to the addition of a PCM USB device.
On Wed, Mar 15, 2023 at 09:30:58AM -0500, Pierre-Louis Bossart wrote: > That's probably ok then, am I getting this right that the the DSP card > would not expose any USB-related kcontrols then, i.e. the ONLY path to > change volumes, etc., would through the regular USB card kcontrols? > That would limit the changes in the platform sound card to the addition > of a PCM USB device. I'd guess that there might be some volume control in the DSP as part of the generic routing to the port (eg, if all ports have some output control) but I'm not sure that's an issue, could even be useful for normalising the output of DSP algorithms compared to direct PCM playback.
Hi Pierre, On 3/15/2023 7:30 AM, Pierre-Louis Bossart wrote: > Hi Wesley, > >> Sorry made a mistake on the diagram. There is no connection from >> SOC-USB to the APR/GLINK. The Q6USB driver will be the one that is >> going to configure some of the Q6AFE ports along withe the Q6AFE DAI >> driver. >> >> | ASoC >> ---------------------------------- >> | _________________________ >> | |sm8250 platform card | >> | |_________________________| >> | | | >> | ___V____ ____V____ >> | |Q6USB | |Q6AFE | #5 >> | |"codec" | |"cpu" | >> | |________| |_________| >> | ^ ^ ^ >> | #6 | |________| >> | ___V____ | >> | |SOC-USB | | >> #7 | | | >> ----->|________| | >> --- | >> | | | >> | | _____________V________ >> | | |APR/GLINK | >> | | |______________________| >> | | ^ >> | | #8 | >> | | ___________V___________ >> | |->|audio DSP | >> | |_______________________| >> | >> | >> >>>> > > Makes sense now, thank you for the clarification. > > I'll have to dig more in this 'soc-usb' block, it's clearly a key > component that will have to maintain a consistent state across two > different parts of the stack and deal with probe/remove/shutdown. > >>> My initial thought was to add a 'DSP offload' PCM to the USB card, you >>> added a "USB offload" PCM to the DSP card. Nice logical swap! >>> >>> Your proposal might be easier in practice since there's typically a >>> vendor-specific configuration file (UCM or custom) file for the DSP, >>> where USB information can be added. >>> >>> It's more problematic to change a generic USB card as we know it today >>> and bolt vendor-specific DSP information on top. >>> >>> The only open I have with your option is that there are still two >>> control paths to e.g. set the volume. It would be so much easier for >>> userspace if there was a single volume control no matter what path is >>> used for data, or make sure the kcontrols are 'mirrored' somehow. If we >>> found a way to address this issue that would be ideal. >>> >> >> Got it. Let me look to see if that is something we can address/add. I >> think the current implementation is that USB SND will expose some mixer >> controls based on the UAC descriptor parsing. Then when they want to >> change the volume (for example) it will result in a USB SETUP transaction. >> >> So USB SND will eventually be the entity controlling these changes. > > That's probably ok then, am I getting this right that the the DSP card > would not expose any USB-related kcontrols then, i.e. the ONLY path to > change volumes, etc., would through the regular USB card kcontrols? > > That would limit the changes in the platform sound card to the addition > of a PCM USB device. Yes, that's correct. There won't be any exposed USB volume controls from the DSP card. Thanks Wesley Cheng
Changes in v3: - Changed prefix from RFC to PATCH - Rebased entire series to usb-next - Updated copyright years XHCI: - Rebased changes on top of XHCI changes merged into usb-next, and only added changes that were still under discussion. - Added change to read in the "num-hc-interrupters" device property. ASoC: - qusb6 USB backend - Incorporated suggestions to fetch iommu information with existing APIs - Added two new sound kcontrols to fetch offload status and offload device selection. - offload status - will return the card and pcm device in use tinymix -D 0 get 1 --> 1, 0 (offload in progress on card#1 pcm#0) - device selection - set the card and pcm device to enable offload on. Ex.: tinymix -D 0 set 1 2 0 --> sets offload on card#2 pcm#0 (this should be the USB card) USB SND: - Fixed up some locking related concerns for registering platform ops. - Moved callbacks under the register_mutex, so that - Modified APIs to properly pass more information about the USB SND device, so that the Q6USB backend can build a device list/map, in order to monitor offload status and device selection. Changes in v2: XHCI: - Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes in his tree: https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters Adjustments made to Mathias' changes: - Created xhci-intr.h to export/expose interrupter APIs versus exposing xhci.h. Moved dependent structures to this file as well. (so clients can parse out information from "struct xhci_interrupter") - Added some basic locking when requesting interrupters. - Fixed up some sanity checks. - Removed clearing of the ERSTBA during freeing of the interrupter. (pending issue where SMMU fault occurs if DMA addr returned is 64b - TODO) - Clean up pending events in the XHCI secondary interrupter. While testing USB bus suspend, it was seen that on bus resume, the xHCI HC would run into a command timeout. - Added offloading APIs to xHCI to fetch transfer and event ring information. ASoC: - Modified soc-usb to allow for multiple USB port additions. For this to work, the USB offload driver has to have a reference to the USB backend by adding a "usb-soc-be" DT entry to the device saved into XHCI sysdev. - Created separate dt-bindings for defining USB_RX port. - Increased APR timeout to accommodate the situation where the AFE port start command could be delayed due to having to issue a USB bus resume while handling the QMI stream start command. USB SND: - Added a platform ops during usb_audio_suspend(). This allows for the USB offload driver to halt the audio stream when system enters PM suspend. This ensures the audio DSP is not issuing transfers on the USB bus. - Do not override platform ops if they are already populated. - Introduce a shared status variable between the USB offload and USB SND layers, to ensure that only one path is active at a time. If the USB bus is occupied, then userspace is notified that the path is busy. Several Qualcomm based chipsets can support USB audio offloading to a dedicated audio DSP, which can take over issuing transfers to the USB host controller. The intention is to reduce the load on the main processors in the SoC, and allow them to be placed into lower power modes. There are several parts to this design: 1. Adding ASoC binding layer 2. Create a USB backend for Q6DSP 3. Introduce XHCI interrupter support 4. Create vendor ops for the USB SND driver Adding ASoC binding layer: soc-usb: Intention is to treat a USB port similar to a headphone jack. The port is always present on the device, but cable/pin status can be enabled/disabled. Expose mechanisms for USB backend ASoC drivers to communicate with USB SND. Create a USB backend for Q6DSP: q6usb: Basic backend driver that will be responsible for maintaining the resources needed to initiate a playback stream using the Q6DSP. Will be the entity that checks to make sure the connected USB audio device supports the requested PCM format. If it does not, the PCM open call will fail, and userpsace ALSA can take action accordingly. Introduce XHCI interrupter support: XHCI HCD supports multiple interrupters, which allows for events to be routed to different event rings. This is determined by "Interrupter Target" field specified in Section "6.4.1.1 Normal TRB" of the XHCI specification. Events in the offloading case will be routed to an event ring that is assigned to the audio DSP. Create vendor ops for the USB SND driver: qc_audio_offload: This particular driver has several components associated with it: - QMI stream request handler - XHCI interrupter and resource management - audio DSP memory management When the audio DSP wants to enable a playback stream, the request is first received by the ASoC platform sound card. Depending on the selected route, ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI will send an AFE port start command (with enabling the USB playback path), and the audio DSP will handle the request accordingly. Part of the AFE USB port start handling will have an exchange of control messages using the QMI protocol. The qc_audio_offload driver will populate the buffer information: - Event ring base address - EP transfer ring base address and pass it along to the audio DSP. All endpoint management will now be handed over to the DSP, and the main processor is not involved in transfers. Overall, implementing this feature will still expose separate sound card and PCM devices for both the platorm card and USB audio device: 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D SM8250-MTP-WCD9380-WSA8810-VA-DMIC 1 [Audio ]: USB-Audio - USB Audio Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed This is to ensure that userspace ALSA entities can decide which route to take when executing the audio playback. In the above, if card#1 is selected, then USB audio data will take the legacy path over the USB PCM drivers, etc... This feature was validated using: - tinymix: set/enable the multimedia path to route to USB backend - tinyplay: issue playback on platform card Mathias Nyman (1): xhci: Add support to allocate several interrupters Wesley Cheng (27): usb: xhci: Add XHCI APIs to support USB offloading usb: host: xhci-mem: Cleanup pending secondary event ring events ASoC: Add SOC USB APIs for adding an USB backend ASoC: dt-bindings: qcom,q6dsp-lpass-ports: Add USB_RX port ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp ASoC: qdsp6: q6afe: Increase APR timeout ASoC: qcom: Add USB backend ASoC driver for Q6 sound: usb: card: Introduce USB SND platform op callbacks sound: usb: Export USB SND APIs for modules dt-bindings: usb: dwc3: Add snps,num-hc-interrupters definition usb: dwc3: Add DT parameter to specify maximum number of interrupters usb: host: xhci-plat: Set XHCI max interrupters if property is present sound: usb: pcm: Export fixed rate check USB SND API sound: usb: Introduce QC USB SND offloading support sound: usb: card: Check for support for requested audio format sound: soc: soc-usb: Add PCM format check API for USB backend sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio device sound: usb: Prevent starting of audio stream if in use ASoC: dt-bindings: Add Q6USB backend bindings ASoC: dt-bindings: Update example for enabling USB offload on SM8250 ASoC: qcom: qdsp6: q6afe: Split USB AFE dev_token param into separate API sound: Pass USB SND card and PCM information to SOC USB sound: soc: qdsp6: Add SND kcontrol to select offload device sound: soc: qdsp6: Add SND kcontrol for fetching offload status sound: usb: qc_audio_offload: Use card and PCM index from QMI request sound: usb: card: Allow for rediscovery of connected USB SND devices sound: soc: soc-usb: Rediscover USB SND devices on USB port add .../bindings/sound/qcom,q6usb-dais.yaml | 49 + .../bindings/sound/qcom,sm8250.yaml | 15 + .../devicetree/bindings/usb/snps,dwc3.yaml | 13 + drivers/usb/dwc3/core.c | 12 + drivers/usb/dwc3/core.h | 2 + drivers/usb/dwc3/host.c | 5 +- drivers/usb/host/xhci-debugfs.c | 2 +- drivers/usb/host/xhci-mem.c | 171 +- drivers/usb/host/xhci-plat.c | 2 + drivers/usb/host/xhci-ring.c | 2 +- drivers/usb/host/xhci.c | 181 +- drivers/usb/host/xhci.h | 2 +- .../sound/qcom,q6dsp-lpass-ports.h | 1 + include/linux/usb/xhci-intr.h | 94 + include/sound/pcm_params.h | 4 + include/sound/q6usboffload.h | 20 + include/sound/soc-usb.h | 39 + sound/core/oss/pcm_oss.c | 58 - sound/core/pcm_lib.c | 65 + sound/soc/Makefile | 2 +- sound/soc/qcom/Kconfig | 4 + sound/soc/qcom/qdsp6/Makefile | 1 + sound/soc/qcom/qdsp6/q6afe-dai.c | 50 + sound/soc/qcom/qdsp6/q6afe.c | 208 +- sound/soc/qcom/qdsp6/q6afe.h | 47 +- sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c | 23 + sound/soc/qcom/qdsp6/q6dsp-lpass-ports.h | 1 + sound/soc/qcom/qdsp6/q6routing.c | 9 + sound/soc/qcom/qdsp6/q6usb.c | 445 ++++ sound/soc/soc-usb.c | 197 ++ sound/usb/Kconfig | 14 + sound/usb/Makefile | 2 +- sound/usb/card.c | 85 + sound/usb/card.h | 31 + sound/usb/endpoint.c | 2 + sound/usb/helper.c | 1 + sound/usb/pcm.c | 29 +- sound/usb/pcm.h | 12 + sound/usb/qcom/Makefile | 2 + sound/usb/qcom/qc_audio_offload.c | 1790 +++++++++++++++++ sound/usb/qcom/usb_audio_qmi_v01.c | 892 ++++++++ sound/usb/qcom/usb_audio_qmi_v01.h | 162 ++ 42 files changed, 4646 insertions(+), 100 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6usb-dais.yaml create mode 100644 include/linux/usb/xhci-intr.h create mode 100644 include/sound/q6usboffload.h create mode 100644 include/sound/soc-usb.h create mode 100644 sound/soc/qcom/qdsp6/q6usb.c create mode 100644 sound/soc/soc-usb.c create mode 100644 sound/usb/qcom/Makefile create mode 100644 sound/usb/qcom/qc_audio_offload.c create mode 100644 sound/usb/qcom/usb_audio_qmi_v01.c create mode 100644 sound/usb/qcom/usb_audio_qmi_v01.h