the ASoC layer does require a driver with a 'name' for the components
registered with the master device. So if you don't have a driver for the
master device, the DAIs will be associated with the PCI device.
But the ASoC core does make pm_runtime calls on its own,
soc_pcm_open(struct snd_pcm_substream *substream)
{
...
for_each_rtd_components(rtd, i, component)
pm_runtime_get_sync(component->dev);
and if the device that's associated with the DAI is the PCI device, then
that will not result in the relevant master IP being activated, only the PCI
device refcount will be increased - meaning there is no hook that would tell
the PCI layer to turn on a specific link.
What you are recommending would be an all-or-nothing solution with all links
on or all links off, which beats the purpose of having independent
link-level power management.
Why can't you use dai .startup callback for this?
The ASoC core will do pm_runtime calls that will ensure PCI device is
up, DSP firmware downloaded and running.
You can use .startup() to turn on your link and .shutdown to turn off
the link.
There are multiple dais per link, and multiple Slave per link, so we would
have to refcount and track active dais to understand when the link needs to
be turned on/off. It's a duplication of what the pm framework can do at the
device/link level, and will likely introduce race conditions.
Not to mention that we'd need to introduce workqueues to turn the link off
with a delay, with pm_runtime_put_autosuspend() does for free.
Yes sure, that seems to be the cost unfortunately. While it might feel I
am blocking but the real block here is the hw design which gives you a
monolith whereas it should have been different devices. If you have a
'device' for sdw or a standalone controller we would not be debating
this..
The hardware is what it is. The ACPI spec is what it is.
I am just pragmatic and making platforms work with that's available
*today*, and I don't have time or interest in revisiting what might have
been.
Linux is all about frameworks. For power management, we shall use the power
management framework, not reinvent it.
This reminds me, please talk to Mika and Rafael, they had similar
problems with lpss etc and IIRC they were working on splices to solve
this.. Its been some time (few years now) so maybe they have a
solution..
We've been discussing this since October, I don't really have any
appetite for looking into new concepts when the existing framework just
does what we need.
It's really down to your objection to the use of 'struct driver'... For
ASoC support we only need the .name and .pm_ops, so there's really no
possible path forward otherwise.
Like I said, we have 3 options
a) stay with platform devices for now. You will need to have a
conversation with Greg on this.
b) use a minimal sdw_master_device with a minimal 'struct driver' use.
c) use a more elaborate solution suggested in this patchset and yes that
means the Qualcomm driver would need to change a bit.
Pick one or suggest something that is implementable. The first version
of the patches was provided in October, the last RFC was provided on
January 31, time's up. At the moment you are preventing ASoC integration
from moving forward.
Thanks
-Pierre
