Message ID | 20240213005422.3121-1-quic_wcheng@quicinc.com |
---|---|
Headers | show |
Series | Introduce QC USB SND audio offloading support | expand |
Hi Takashi, On 2/13/2024 4:10 AM, Takashi Iwai wrote: > On Tue, 13 Feb 2024 01:54:13 +0100, > Wesley Cheng wrote: >> >> Add a kcontrol to the platform sound card to fetch the current offload >> status. This can allow for userspace to ensure/check which USB SND >> resources are actually busy versus having to attempt opening the USB SND >> devices, which will result in an error if offloading is active. >> >> An example of fetching the USB offloading status would look like: >> tinymix -D 0 get 'USB Offload Playback Route Status' >> -1, -1 (range -1->32) --> [Offload is idle] >> >> tinymix -D 0 get 'USB Offload Playback Route Status' >> 1, 0 (range -1->32) --> [Offload active on card#1 pcm#0] > > Ah, I didn't notice until now that the second value is the PCM index. > >> +static int snd_soc_usb_offload_status_info(struct snd_kcontrol *kcontrol, >> + struct snd_ctl_elem_info *uinfo) >> +{ >> + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); >> + struct snd_soc_usb *ctx = snd_soc_find_usb_ctx(component->dev->of_node); >> + >> + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; >> + uinfo->count = 2*ctx->num_supported_streams; >> + uinfo->value.integer.min = -1; >> + uinfo->value.integer.max = SNDRV_CARDS; > > Then it's bogus to set SNDRV_CARDS as max. The PCM index number is > independent from the card number. In theory, it can be even more than > the card max (very unlikely, though). > I don't think its technically capped anywhere :). I just used SNDRV_CARDS to cap the sound card number. If I split this as a separate entity, then I'll need to change the max value for the PCM dev. > Wouldn't it be more intuitive to provide two different controls, one > for card number and one for PCM index number? > Sure, I can split this up. Thanks Wesley Cheng
Hi Takashi, On 2/13/2024 4:18 AM, Takashi Iwai wrote: > On Tue, 13 Feb 2024 01:54:18 +0100, > Wesley Cheng wrote: >> >> --- a/sound/usb/Makefile >> +++ b/sound/usb/Makefile >> @@ -22,6 +22,7 @@ snd-usb-audio-objs := card.o \ >> stream.o \ >> validate.o >> >> +snd-usb-audio-$(CONFIG_SND_USB_OFFLOAD_MIXER) += mixer_usb_offload.o >> snd-usb-audio-$(CONFIG_SND_USB_AUDIO_MIDI_V2) += midi2.o >> snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o > > This puts the code into snd-usb-audio driver, and that causes a > dependency mess, since... > I see what you mean after moving some things into modules, etc... Will fix this accordingly. >> +snd_usb_offload_available_get(struct snd_kcontrol *kcontrol, >> + struct snd_ctl_elem_value *ucontrol) >> +{ >> + struct device *sysdev = snd_kcontrol_chip(kcontrol); >> + int ret; >> + >> + ret = snd_soc_usb_device_offload_available(sysdev); > > ... here you call snd_soc_usb_*() stuff that belongs to snd-soc-usb. > That is, with this patch, snd-usb-audio driver will depend on > snd-soc-usb, while snd-soc-usb also depends on snd-usb-audio for its > helpers again. > > I believe the better way would be to move this whole miser_usb_offload > code into sound/usb/qcom/. You need only usb_device and snd_card > objects at the creation, and you can get them in qcom driver side, > too. > Yes, plan is just to compile this as part of the overall offload module if the config is enabled. Thanks Wesley Cheng