On Mon, Feb 27, 2023 at 06:59:32PM -0800, Wesley Cheng wrote:
Hi Greg,
On 2/10/2023 2:49 PM, Wesley Cheng wrote:
Hi Greg,
On 1/28/2023 5:28 AM, Greg KH wrote:
On Wed, Jan 25, 2023 at 07:14:14PM -0800, Wesley Cheng wrote:
Allow for different platforms to be notified on USB SND
connect/disconnect
seqeunces. This allows for platform USB SND modules to properly
initialize
and populate internal structures with references to the USB SND chip
device.
Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
---
sound/usb/card.c | 28 ++++++++++++++++++++++++++++
sound/usb/card.h | 20 ++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 26268ffb8274..803230343c16 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -117,6 +117,24 @@ MODULE_PARM_DESC(skip_validation, "Skip
unit descriptor validation (default: no)
static DEFINE_MUTEX(register_mutex);
static struct snd_usb_audio *usb_chip[SNDRV_CARDS];
static struct usb_driver usb_audio_driver;
+static struct snd_usb_platform_ops *platform_ops;
You can not have a single "platform_ops" pointer, this HAS to be
per-bus.
Agreed.
I looked at seeing how we could implement this at a per bus level, but the
USB class driver model doesn't exactly have a good framework for supporting
this. Reason being is because, at the time of the USB SND class driver
initialization, there is a big chance that there isn't a USB bus registered
in the system, so the point of adding the operations is not clear. However,
we need to ensure that we've added the platform/driver operations before any
USB SND devices are detected.
But the offload "engine" is associated with the specific USB bus
controller instance in the system, so perhaps you are just not adding
this to the correct location?
The sound core shouldn't care about this at all, add the logic to the
USB host controller driver instead, why isn't this just another USB bus
function?
To add to the above, in case of OTG/DRD (dual role) designs, the USB HCD/bus
isn't created until we move into the host role. At that time, using DWC3 as
an example, we will create the XHCI platform device, and probe the USB HCD,
where a USB bus is created.
Great, again, tie it to the specific xhci host controler instance.
In general, we currently think this USB offload driver should co-exist with
the USB SND class driver, which handles all devices connected across every
bus.
And that is incorrect, please do not do that.
We can add a check to the platform connect routine to ensure that
there is a reference to the USB backend. If so, then that particular USB
bus/sysdev can be supported by the audio DSP. That way, we do not falsely
populate USB SND cards which are present on another USB bus/controller.
You should NEVER be able to populate a USB card unless the USB bus
controller has given you the USB interface structure to control, so I do
not understand how this is an issue.