| Message ID | 20240801011730.4797-13-quic_wcheng@quicinc.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v24,01/34] xhci: add helper to stop endpoint and wait for completion | expand |
Hi Pierre, On 8/1/2024 1:26 AM, Pierre-Louis Bossart wrote: >> + >> +:: >> + >> + USB | ASoC >> + | _________________________ >> + | | ASoC Platform card | >> + | |_________________________| >> + | | | >> + | ___V____ ____V____ >> + | |ASoC BE | |ASoC FE | >> + | |DAI LNK | |DAI LNK | >> + | |________| |_________| >> + | ^ ^ ^ >> + | | |________| >> + | ___V____ | >> + | |SOC-USB | | >> + ________ ________ | | | >> + |USB SND |<--->|USBSND |<------------>|________| | >> + |(card.c)| |offld |<---------- | >> + |________| |________|___ | | | >> + ^ ^ | | | ____________V_________ >> + | | | | | |IPC | >> + __ V_______________V_____ | | | |______________________| >> + |USB SND (endpoint.c) | | | | ^ >> + |_________________________| | | | | >> + ^ | | | ___________V___________ >> + | | | |->|audio DSP | >> + ___________V_____________ | | |_______________________| >> + |XHCI HCD |<- | >> + |_________________________| | >> + > It wouldn't hurt to describe what you mean by 'port' in this diagram... Sure, as mentioned in my earlier comments, in the USB world, port and device is kind of interchangeable, at least IMO. I'd like to stick with the "port" term, but if you see otherwise, let me know. > >> +SOC USB driver >> +============== >> +Structures >> +---------- >> +``struct snd_soc_usb`` >> + >> + - ``list``: list head for SND SOC struct list >> + - ``component``: reference to ASoC component >> + - ``num_supported_streams``: number of supported concurrent sessions >> + - ``connection_status_cb``: callback to notify connection events >> + - ``get_offload_dev``: callback to fetch selected USB sound card/PCM device > I think you meant fetch offloaded sound card and PCM device information > for a given USB card:device pair? Correct, will change. > >> +Functions >> +--------- >> +.. code-block:: rst >> + >> + const char *snd_soc_usb_get_components_tag(bool playback); >> +.. >> + >> + - ``playback``: direction of audio stream > why not use the usual direction 0: playback and 1: capture? > >> + >> +**snd_soc_usb_get_components_tag()** returns the tag used for describing if USB >> +offloading is supported for appending to a sound card's components string. > How does this work if the ASoC part is probe after the USB card? The > component string would be modified after the creation of the card? > > A control is more dynamic by nature, not sure about this component > string. Jaroslav? Do we actually need to add this? I think just having the kcontrol is sufficient. >> +**snd_soc_usb_add_port()** add an allocated SOC USB device to the SOC USB framework. >> +Once added, this device can be referenced by further operations. >> + >> +.. code-block:: rst >> + >> + void snd_soc_usb_remove_port(struct snd_soc_usb *usb); >> +.. >> + >> + - ``usb``: SOC USB device to remove >> + >> +**snd_soc_usb_remove_port()** removes a SOC USB device from the SOC USB framework. >> +After removing a device, any SOC USB operations would not be able to reference the >> +device removed. > Not clear to me if the notion of 'port' helps, why not just > snd_soc_usb_add_device() and remove_device()? I'm open to either terms, since both mean the same to me :). > >> + >> +USB Offload Related Kcontrols >> +============================= >> +Details >> +------- >> +A set of kcontrols can be utilized by applications to help select the proper sound >> +devices to enable USB audio offloading. SOC USB exposes the get_offload_dev() >> +callback that designs can use to ensure that the proper indices are returned to the >> +application. >> + >> +Implementation >> +-------------- >> + >> +**Example:** >> + >> + **Sound Cards**: >> + >> + :: >> + >> + 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >> + SM8250-MTP-WCD9380-WSA8810-VA-DMIC >> + 1 [Seri ]: USB-Audio - Plantronics Blackwire 3225 Seri >> + Plantronics Plantronics Blackwire 3225 Seri at usb-xhci-hcd.1.auto-1.1, full sp >> + 2 [C320M ]: USB-Audio - Plantronics C320-M >> + Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full speed >> + >> + **USB Sound Card** - card#1: >> + >> + :: >> + >> + USB Offload Playback Route PCM#0 -1, -1 (range -1->255) >> + >> + **USB Sound Card** - card#2: >> + >> + :: >> + >> + USB Offload Playback Route PCM#0 0, 1 (range -1->255) >> + >> +The above example shows a scenario where the system has one ASoC platform card >> +(card#0) and two USB sound devices connected (card#1 and card#2). When reading >> +the available kcontrols for each USB audio device, the following kcontrol lists >> +the mapped offload path for the specific device: >> + >> + "USB Offload Playback Route#*" >> + >> +The kcontrol is indexed, because a USB audio device could potentially have >> +several PCM devices. The above kcontrols are defined as: >> + >> + - ``USB Offload Playback Route PCM`` **(R)**: Returns the ASoC platform sound >> + card and PCM device index. The output "0, 1" (card index, PCM device index) >> + signifies that there is an available offload path for the USB SND device >> + through card#0-PCM device#1. If "-1, -1" is seen, then no offload path is >> + available for the USB SND device. >> + >> +USB Offload Playback Route Kcontrol >> +----------------------------------- >> +In order to allow for vendor specific implementations on audio offloading device >> +selection, the SOC USB layer exposes the following: >> + >> +.. code-block:: rst >> + >> + int (*get_offload_dev)(struct snd_kcontrol *kcontrol, >> + struct snd_ctl_elem_value *ucontrol); >> +.. >> + >> +These are specific for the **USB Offload Playback Route PCM#** kcontrol. >> + >> +When users issue get calls to the kcontrol, the registered SOC USB callbacks will >> +execute the registered function calls to the DPCM BE DAI link. > Oh man, now I get what 'get_offload_dev" means: it really means > "update_offload_info' or 'update_info_kcontrol". > The 'get' routines usually provide a handle on something to another part > of the kernel. > Not here, it's an update of something to be looked-up by userspace... > I can change the naming for this if its not the right terms used. As long as you understand how the concept works then the name changing isn't a problem. Thanks Wesley Cheng >> +**Callback Registration:** >> + >> +.. code-block:: rst >> + >> + static int q6usb_component_probe(struct snd_soc_component *component) >> + { >> + ... >> + usb = snd_soc_usb_allocate_port(component, 1, &data->priv); >> + if (IS_ERR(usb)) >> + return -ENOMEM; >> + >> + usb->connection_status_cb = q6usb_alsa_connection_cb; >> + usb->get_offload_dev = q6usb_get_offload_dev; >> + >> + ret = snd_soc_usb_add_port(usb); >> +..
On 8/1/2024 3:17 AM, Wesley Cheng wrote: > With the introduction of the soc-usb driver, add documentation highlighting > details on how to utilize the new driver and how it interacts with > different components in USB SND and ASoC. It provides examples on how to > implement the drivers that will need to be introduced in order to enable > USB audio offloading. > > Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> > --- (...) > + > +One potential use case would be to support USB audio offloading, which is > +an implementation that allows for an external DSP on the SoC to handle the > +transfer of audio data over the USB bus. This would let the main > +processor to stay in lower power modes for longer durations. The following *duration (...) > + > +In order to account for conditions where driver or device existence is > +not guaranteed, USB SND exposes snd_usb_rediscover_devices() to resend the > +connect events for any identified USB audio interfaces. Consider the > +the following situtation: *situation > +USB Offload Related Kcontrols > +============================= > +Details > +------- > +A set of kcontrols can be utilized by applications to help select the proper sound > +devices to enable USB audio offloading. SOC USB exposes the get_offload_dev() > +callback that designs can use to ensure that the proper indices are returned to the > +application. At the moment I only see getter below, how does application set it? > + > +Implementation > +-------------- > + > +**Example:** > + > + **Sound Cards**: > + > + :: > + > + 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D > + SM8250-MTP-WCD9380-WSA8810-VA-DMIC > + 1 [Seri ]: USB-Audio - Plantronics Blackwire 3225 Seri > + Plantronics Plantronics Blackwire 3225 Seri at usb-xhci-hcd.1.auto-1.1, full sp > + 2 [C320M ]: USB-Audio - Plantronics C320-M > + Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full speed > + > + **USB Sound Card** - card#1: > + > + :: > + > + USB Offload Playback Route PCM#0 -1, -1 (range -1->255) > + > + **USB Sound Card** - card#2: > + > + :: > + > + USB Offload Playback Route PCM#0 0, 1 (range -1->255) > + > +The above example shows a scenario where the system has one ASoC platform card > +(card#0) and two USB sound devices connected (card#1 and card#2). When reading > +the available kcontrols for each USB audio device, the following kcontrol lists > +the mapped offload path for the specific device: > + > + "USB Offload Playback Route#*" > + > +The kcontrol is indexed, because a USB audio device could potentially have > +several PCM devices. The above kcontrols are defined as: > + > + - ``USB Offload Playback Route PCM`` **(R)**: Returns the ASoC platform sound > + card and PCM device index. The output "0, 1" (card index, PCM device index) > + signifies that there is an available offload path for the USB SND device > + through card#0-PCM device#1. If "-1, -1" is seen, then no offload path is > + available for the USB SND device. > + That's better, although I'm still not convinced end users care where offload happens. Few questions though, so I'm sure I understand how it works: Does "0, 1" in this case means that if you try to open device 1 on card 0, you won't be able to do it, because it is offloading USB? In case it is "-1, -1" is there a chance that it can change?
Hi Amadeusz, On 8/6/2024 7:51 AM, Amadeusz Sławiński wrote: > On 8/1/2024 3:17 AM, Wesley Cheng wrote: >> With the introduction of the soc-usb driver, add documentation highlighting >> details on how to utilize the new driver and how it interacts with >> different components in USB SND and ASoC. It provides examples on how to >> implement the drivers that will need to be introduced in order to enable >> USB audio offloading. >> >> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >> --- > > (...) > >> + >> +One potential use case would be to support USB audio offloading, which is >> +an implementation that allows for an external DSP on the SoC to handle the >> +transfer of audio data over the USB bus. This would let the main >> +processor to stay in lower power modes for longer durations. The following > > *duration > > (...) > >> + >> +In order to account for conditions where driver or device existence is >> +not guaranteed, USB SND exposes snd_usb_rediscover_devices() to resend the >> +connect events for any identified USB audio interfaces. Consider the >> +the following situtation: > > *situation > >> +USB Offload Related Kcontrols >> +============================= >> +Details >> +------- >> +A set of kcontrols can be utilized by applications to help select the proper sound >> +devices to enable USB audio offloading. SOC USB exposes the get_offload_dev() >> +callback that designs can use to ensure that the proper indices are returned to the >> +application. > > At the moment I only see getter below, how does application set it? > >> + >> +Implementation >> +-------------- >> + >> +**Example:** >> + >> + **Sound Cards**: >> + >> + :: >> + >> + 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D >> + SM8250-MTP-WCD9380-WSA8810-VA-DMIC >> + 1 [Seri ]: USB-Audio - Plantronics Blackwire 3225 Seri >> + Plantronics Plantronics Blackwire 3225 Seri at usb-xhci-hcd.1.auto-1.1, full sp >> + 2 [C320M ]: USB-Audio - Plantronics C320-M >> + Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full speed >> + >> + **USB Sound Card** - card#1: >> + >> + :: >> + >> + USB Offload Playback Route PCM#0 -1, -1 (range -1->255) >> + >> + **USB Sound Card** - card#2: >> + >> + :: >> + >> + USB Offload Playback Route PCM#0 0, 1 (range -1->255) >> + >> +The above example shows a scenario where the system has one ASoC platform card >> +(card#0) and two USB sound devices connected (card#1 and card#2). When reading >> +the available kcontrols for each USB audio device, the following kcontrol lists >> +the mapped offload path for the specific device: >> + >> + "USB Offload Playback Route#*" >> + >> +The kcontrol is indexed, because a USB audio device could potentially have >> +several PCM devices. The above kcontrols are defined as: >> + >> + - ``USB Offload Playback Route PCM`` **(R)**: Returns the ASoC platform sound >> + card and PCM device index. The output "0, 1" (card index, PCM device index) >> + signifies that there is an available offload path for the USB SND device >> + through card#0-PCM device#1. If "-1, -1" is seen, then no offload path is >> + available for the USB SND device. >> + > > That's better, although I'm still not convinced end users care where offload happens. > > Few questions though, so I'm sure I understand how it works: > Does "0, 1" in this case means that if you try to open device 1 on card 0, you won't be able to do it, because it is offloading USB? > No, it means that if you open device 1 on card 0, that will be the USB offload path to the USB audio device. > In case it is "-1, -1" is there a chance that it can change? > It can change to non-negative when the offload path is enabled for that device. Currently, since we removed the device selection logic entirely (for now), if say you have 2 USB audio devices connected. As mentioned previously, we will select the latest USB headset connected, and the other will have "-1, -1" as the output when reading its controls. Now, if the last USB headset is unplugged, then there is still an available USB device that can be offloaded, so it will switch to allowing that device to be offloaded, and you should see that be a non-negative kcontrol. Thanks Wesley Cheng
diff --git a/Documentation/sound/soc/index.rst b/Documentation/sound/soc/index.rst index e57df2dab2fd..8bed8f8f48da 100644 --- a/Documentation/sound/soc/index.rst +++ b/Documentation/sound/soc/index.rst @@ -18,3 +18,4 @@ The documentation is spilt into the following sections:- jack dpcm codec-to-codec + usb diff --git a/Documentation/sound/soc/usb.rst b/Documentation/sound/soc/usb.rst new file mode 100644 index 000000000000..acd90ad0a4d9 --- /dev/null +++ b/Documentation/sound/soc/usb.rst @@ -0,0 +1,435 @@ +================ +ASoC USB support +================ + +Overview +======== +In order to leverage the existing USB sound device support in ALSA, the +ASoC USB APIs are introduced to allow for the entities to communicate +with one another. + +One potential use case would be to support USB audio offloading, which is +an implementation that allows for an external DSP on the SoC to handle the +transfer of audio data over the USB bus. This would let the main +processor to stay in lower power modes for longer durations. The following +is an example design of how the ASoC and ALSA pieces can be connected +together to achieve this: + +:: + + USB | ASoC + | _________________________ + | | ASoC Platform card | + | |_________________________| + | | | + | ___V____ ____V____ + | |ASoC BE | |ASoC FE | + | |DAI LNK | |DAI LNK | + | |________| |_________| + | ^ ^ ^ + | | |________| + | ___V____ | + | |SOC-USB | | + ________ ________ | | | + |USB SND |<--->|USBSND |<------------>|________| | + |(card.c)| |offld |<---------- | + |________| |________|___ | | | + ^ ^ | | | ____________V_________ + | | | | | |IPC | + __ V_______________V_____ | | | |______________________| + |USB SND (endpoint.c) | | | | ^ + |_________________________| | | | | + ^ | | | ___________V___________ + | | | |->|audio DSP | + ___________V_____________ | | |_______________________| + |XHCI HCD |<- | + |_________________________| | + + +SOC USB driver +============== +Structures +---------- +``struct snd_soc_usb`` + + - ``list``: list head for SND SOC struct list + - ``component``: reference to ASoC component + - ``num_supported_streams``: number of supported concurrent sessions + - ``connection_status_cb``: callback to notify connection events + - ``get_offload_dev``: callback to fetch selected USB sound card/PCM device + - ``priv_data``: driver data + +The snd_soc_usb structure can be referenced using the ASoC platform card +device, or a USB device (udev->dev). This is created by the ASoC BE DAI +link, and the USB sound entity will be able to pass information to the +ASoC BE DAI link using this structure. + +``struct snd_soc_usb_device`` + + - ``card_idx``: sound card index associated with USB sound device + - ``pcm_idx``: pcm device index associated with the USB sound device + - ``chip_idx``: USB sound chip array index + - ``num_playback``: number of playback streams + - ``num_capture``: number of capture streams + - ``list``: list head for the USB sound device list + +The struct snd_soc_usb_device is created by the USB sound offload driver. +This will carry basic parameters/limitations that will be used to +determine the possible offloading paths for this USB audio device. + +Functions +--------- +.. code-block:: rst + + const char *snd_soc_usb_get_components_tag(bool playback); +.. + + - ``playback``: direction of audio stream + +**snd_soc_usb_get_components_tag()** returns the tag used for describing if USB +offloading is supported for appending to a sound card's components string. + +Returns a tag based on the direction of the audio stream. + +.. code-block:: rst + + int snd_soc_usb_find_format(int card_idx, struct snd_pcm_hw_params *params, + int direction) +.. + + - ``card_idx``: the index into the USB sound chip array. + - ``params``: Requested PCM parameters from the USB DPCM BE DAI link + - ``direction``: capture or playback + +**snd_soc_usb_find_format()** ensures that the requested audio profile being +requested by the external DSP is supported by the USB device. + +Returns 0 on success, and -EOPNOTSUPP on failure. + +.. code-block:: rst + + int snd_soc_usb_connect(struct device *usbdev, struct snd_soc_usb_device *sdev) +.. + + - ``usbdev``: the usb device that was discovered + - ``sdev``: capabilities of the device + +**snd_soc_usb_connect()** notifies the ASoC USB DCPM BE DAI link of a USB +audio device detection. This can be utilized in the BE DAI +driver to keep track of available USB audio devices. This is intended +to be called by the USB offload driver residing in USB SND. + +Returns 0 on success, negative error code on failure. + +.. code-block:: rst + + int snd_soc_usb_disconnect(struct device *usbdev, struct snd_soc_usb_device *sdev) +.. + + - ``usbdev``: the usb device that was removed + - ``sdev``: capabilities to free + +**snd_soc_usb_disconnect()** notifies the ASoC USB DCPM BE DAI link of a USB +audio device removal. This is intended to be called by the USB offload +driver that resides in USB SND. + +.. code-block:: rst + + void *snd_soc_usb_find_priv_data(struct device *usbdev) +.. + + - ``usbdev``: the usb device to reference to find private data + +**snd_soc_usb_find_priv_data()** fetches the private data saved to the SOC USB +device. + +Returns pointer to priv_data on success, NULL on failure. + +.. code-block:: rst + + int snd_soc_usb_setup_offload_jack(struct snd_soc_component *component) +.. + + - ``component``: ASoC component to add the jack + +**snd_soc_usb_setup_offload_jack()** is a helper to add a sound jack control to +the platform sound card. This will allow for consistent naming to be used on +designs that support USB audio offloading. + +Returns 0 on success, negative otherwise. + +.. code-block:: rst + + int snd_soc_usb_disable_offload_jack(struct snd_soc_component *component) +.. + + - ``component``: ASoC component to disable the jack + +**snd_soc_usb_disable_offload_jack()** is a helper to disable a sound jack control +on the platform sound card. + +Returns 0 on success, negative otherwise. + +.. code-block:: rst + + int soc_usb_get_offload_device(struct device *dev, int card, int pcm, + enum snd_soc_usb_kctl route) +.. + + - ``dev``: USB device to look up offload path mapping + - ``card``: USB sound card index + - ``pcm``: USB sound PCM device index + - ``route``: kcontrol type + +**soc_usb_get_offload_device()** is a registered callback to the USB BE DAI link +to fetch the information about the mapped ASoC devices for executing USB audio +offload for the device. + +Returns 0 on success, negative otherwise. + +.. code-block:: rst + + struct snd_soc_usb *snd_soc_usb_allocate_port(struct snd_soc_component *component, + int num_supported_streams, void *data); +.. + + - ``component``: DPCM BE DAI link component + - ``num_supported_streams``: number of active streams supported by external DSP + - ``data``: private data + +**snd_soc_usb_allocate_port()** allocates a SOC USB device and populates standard +parameters that is used for further operations. + +Returns a pointer to struct soc_usb on success, negative on error. + +.. code-block:: rst + + void snd_soc_usb_free_port(struct snd_soc_usb *usb); +.. + + - ``usb``: SOC USB device to free + +**snd_soc_usb_free_port()** frees a SOC USB device. + +.. code-block:: rst + + void snd_soc_usb_add_port(struct snd_soc_usb *usb); +.. + + - ``usb``: SOC USB device to add + +**snd_soc_usb_add_port()** add an allocated SOC USB device to the SOC USB framework. +Once added, this device can be referenced by further operations. + +.. code-block:: rst + + void snd_soc_usb_remove_port(struct snd_soc_usb *usb); +.. + + - ``usb``: SOC USB device to remove + +**snd_soc_usb_remove_port()** removes a SOC USB device from the SOC USB framework. +After removing a device, any SOC USB operations would not be able to reference the +device removed. + +How to Register to SOC USB +-------------------------- +The ASoC DPCM USB BE DAI link is the entity responsible for allocating and +registering the SOC USB device on the component bind. Likewise, it will +also be responsible for freeing the allocated resources. An example can +be shown below: + +.. code-block:: rst + + static int q6usb_component_probe(struct snd_soc_component *component) + { + ... + data->usb = snd_soc_usb_allocate_port(component, 1, &data->priv); + if (!data->usb) + return -ENOMEM; + + usb->connection_status_cb = q6usb_alsa_connection_cb; + + ret = snd_soc_usb_add_port(usb); + if (ret < 0) { + dev_err(component->dev, "failed to add usb port\n"); + goto free_usb; + } + ... + } + + static void q6usb_component_remove(struct snd_soc_component *component) + { + ... + snd_soc_usb_remove_port(data->usb); + snd_soc_usb_free_port(data->usb); + } + + static const struct snd_soc_component_driver q6usb_dai_component = { + .probe = q6usb_component_probe, + .remove = q6usb_component_remove, + .name = "q6usb-dai-component", + ... + }; +.. + +BE DAI links can pass along vendor specific information as part of the +call to allocate the SOC USB device. This will allow any BE DAI link +parameters or settings to be accessed by the USB offload driver that +resides in USB SND. + +USB Audio Device Connection Flow +-------------------------------- +USB devices can be hotplugged into the USB root hub at any point in time. +The BE DAI link should be aware of the current state of the physical USB +port, i.e. if there are any USB devices with audio interface(s) connected. +connection_status_cb() can be used to notify the BE DAI link of any change. + +This is called whenever there is a USB SND interface bind or remove event, +using snd_soc_usb_connect() or snd_soc_usb_disconnect(): + +.. code-block:: rst + + static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip) + { + ... + snd_soc_usb_connect(usb_get_usb_backend(udev), sdev); + ... + } + + static void qc_usb_audio_offload_disconnect(struct snd_usb_audio *chip) + { + ... + snd_soc_usb_disconnect(usb_get_usb_backend(chip->dev), dev->sdev); + ... + } +.. + +In order to account for conditions where driver or device existence is +not guaranteed, USB SND exposes snd_usb_rediscover_devices() to resend the +connect events for any identified USB audio interfaces. Consider the +the following situtation: + + **usb_audio_probe()** + | --> USB audio streams allocated and saved to usb_chip[] + | --> Propagate connect event to USB offload driver in USB SND + | --> **snd_soc_usb_connect()** exits as USB BE DAI link is not ready + + BE DAI link component probe + | --> DAI link is probed and SOC USB port is allocated + | --> The USB audio device connect event is missed + +To ensure connection events are not missed, **snd_usb_rediscover_devices()** +is executed when the SOC USB device is registered. Now, when the BE DAI +link component probe occurs, the following highlights the sequence: + + BE DAI link component probe + | --> DAI link is probed and SOC USB port is allocated + | --> SOC USB device added, and **snd_usb_rediscover_devices()** runs + + **snd_usb_rediscover_devices()** + | --> Traverses through usb_chip[] and for non-NULL entries issue + | **connection_status_cb()** + +In the case where the USB offload driver is unbound, while USB SND is ready, +the **snd_usb_rediscover_devices()** is called during module init. This allows +for the offloading path to also be enabled with the following flow: + + **usb_audio_probe()** + | --> USB audio streams allocated and saved to usb_chip[] + | --> Propagate connect event to USB offload driver in USB SND + | --> USB offload driver **NOT** ready! + + BE DAI link component probe + | --> DAI link is probed and SOC USB port is allocated + | --> No USB connect event due to missing USB offload driver + + USB offload driver probe + | --> **qc_usb_audio_offload_init()** + | --> Calls **snd_usb_rediscover_devices()** to notify of devices + +USB Offload Related Kcontrols +============================= +Details +------- +A set of kcontrols can be utilized by applications to help select the proper sound +devices to enable USB audio offloading. SOC USB exposes the get_offload_dev() +callback that designs can use to ensure that the proper indices are returned to the +application. + +Implementation +-------------- + +**Example:** + + **Sound Cards**: + + :: + + 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D + SM8250-MTP-WCD9380-WSA8810-VA-DMIC + 1 [Seri ]: USB-Audio - Plantronics Blackwire 3225 Seri + Plantronics Plantronics Blackwire 3225 Seri at usb-xhci-hcd.1.auto-1.1, full sp + 2 [C320M ]: USB-Audio - Plantronics C320-M + Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full speed + + **USB Sound Card** - card#1: + + :: + + USB Offload Playback Route PCM#0 -1, -1 (range -1->255) + + **USB Sound Card** - card#2: + + :: + + USB Offload Playback Route PCM#0 0, 1 (range -1->255) + +The above example shows a scenario where the system has one ASoC platform card +(card#0) and two USB sound devices connected (card#1 and card#2). When reading +the available kcontrols for each USB audio device, the following kcontrol lists +the mapped offload path for the specific device: + + "USB Offload Playback Route#*" + +The kcontrol is indexed, because a USB audio device could potentially have +several PCM devices. The above kcontrols are defined as: + + - ``USB Offload Playback Route PCM`` **(R)**: Returns the ASoC platform sound + card and PCM device index. The output "0, 1" (card index, PCM device index) + signifies that there is an available offload path for the USB SND device + through card#0-PCM device#1. If "-1, -1" is seen, then no offload path is + available for the USB SND device. + +USB Offload Playback Route Kcontrol +----------------------------------- +In order to allow for vendor specific implementations on audio offloading device +selection, the SOC USB layer exposes the following: + +.. code-block:: rst + + int (*get_offload_dev)(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol); +.. + +These are specific for the **USB Offload Playback Route PCM#** kcontrol. + +When users issue get calls to the kcontrol, the registered SOC USB callbacks will +execute the registered function calls to the DPCM BE DAI link. + +**Callback Registration:** + +.. code-block:: rst + + static int q6usb_component_probe(struct snd_soc_component *component) + { + ... + usb = snd_soc_usb_allocate_port(component, 1, &data->priv); + if (IS_ERR(usb)) + return -ENOMEM; + + usb->connection_status_cb = q6usb_alsa_connection_cb; + usb->get_offload_dev = q6usb_get_offload_dev; + + ret = snd_soc_usb_add_port(usb); +..
With the introduction of the soc-usb driver, add documentation highlighting details on how to utilize the new driver and how it interacts with different components in USB SND and ASoC. It provides examples on how to implement the drivers that will need to be introduced in order to enable USB audio offloading. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> --- Documentation/sound/soc/index.rst | 1 + Documentation/sound/soc/usb.rst | 435 ++++++++++++++++++++++++++++++ 2 files changed, 436 insertions(+) create mode 100644 Documentation/sound/soc/usb.rst