+extern struct sdw_md_driver intel_sdw_driver;
who uses this intel_sdw_driver? I would assumed someone would register
this with the core...
this is a structure used by intel_init(), see the following code.
+ md = sdw_md_add(&intel_sdw_driver,
+ res->parent,
+ acpi_fwnode_handle(adev),
+ i);
that will in turn call intel_master_probe() as defined below:
+struct sdw_md_driver intel_sdw_driver = {
+ .probe = intel_master_probe,
+ .startup = intel_master_startup,
+
- link->pdev = pdev;
- link++;
+ /* let the SoundWire master driver to its probe */
+ md->driver->probe(md, link);
So you are invoking driver probe here.. That is typically role of driver
core to do that.. If we need that, make driver core do that for you!
That reminds me I am missing match code for master driver...
There is no match for the master because it doesn't have an existence in
ACPI. There are no _ADR or HID that can be used, the only thing that
exists is the Controller which has 4 sublinks. Each master must be added
by hand.
Also the SoundWire master cannot be enumerated or matched against a
SoundWire bus, since it controls the bus itself (that would be a chicken
and egg problem). The SoundWire master would need to be matched on a
parent bus (which does not exist for Intel) since the hardware is
embedded in a larger audio cluster that's visible on PCI only.
Currently for Intel platforms, the SoundWire master device is created by
the SOF driver (via the abstraction in intel_init.c).
So we seem to be somewhere is middle wrt driver probing here! IIUC this
is not a full master driver, thats okay, but then it is not
completely transparent either...
I was somehow thinking that the driver will continue to be
'platform/acpi/of' driver and master device abstraction will be
handled in the core (for example see how the busses like i2c handle
this). The master device is created and used to represent but driver
probing etc is not done
I2C controllers are typically PCI devices or have some sort of ACPI
description. This is not the case for SoundWire masters on Intel
platforms, so even if I wanted to I would have no ability to implement
any matching or parent bus registration.
Also the notion of 'probe' does not necessarily mean that the device is
attached to a bus, we use DAI 'drivers' in ASoC and still have
probe/remove callbacks.
And if you look at the definitions, we added additional callbacks since
probe/remove are not enough to deal with hardware restrictions:
For Intel platforms, we have a startup() callback which is only invoked
once the DSP is powered and the rails stable. Likewise we added an
'autonomous_clock_stop()' callback which will be needed when the Linux
driver hands-over control of the hardware to the DSP firmware, e.g. to
deal with in-band wakes in D0i3.
FWIW, the implementation here follows what was suggested for Greybus
'Host Devices' [1] [2], so it's not like I am creating any sort of
dangerous precedent.
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/greybus/es2.c#L1275
[2] https://elixir.bootlin.com/linux/latest/source/drivers/greybus/hd.c#L124
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
