the SST/SOF driver creates a platform device using the codec _HID as a key
to hard-coded lookup tables in sound/soc/intel/common/soc-acpi*.c - it will
be probed *after* the codec driver probes. I really don't see how to use the
machine driver as currently implemented to establish board-level connections
that would influence the codec driver probe and its use of a clock.
You have the opportunity to run whatever code you want to run at the
point where you're registering your drivers with the system on module
init, things like DMI quirk tables (which is what you're going to need
to do here AFAICT) should work just as well there as they do later on
when the driver loads.
The idea here was to have one single build, and then rely on what the
user configured with initrd override to probe the right I2C codec driver
and indirectly the machine driver. It's similar to device tree overlays.
With the same up2 board, I change the .aml file in
/lib/firmware/acpi-upgrades, swap one HAT board for another and the new
board is handled automagically.
I don't see how I can use hard-coded DMI tables or board-specific things
without losing the single build?
I think you're giving up way too easily here. The kernel has really
good support for systems that don't have any firmware description at
all, this shouldn't be complex or breaking new ground.
See above, I don't think the machine driver can do what you had in mind?
I don't see how to proceed unless we remove all support for ACPI, both for
codec and clock driver, and trigger their probe "manually" with a
board-level initialization.
The clkdev stuff can use dev_name() so so long as the devices appear
with predictable names you should be fine. If not IIRC everything in
ACPI is named in the AML so clkdev could be extended to be able to find
things based on the names it gives.
I had a discussion with Andy Shevchenko that we should precisely not be
using dev_name() since we don't control the names that ACPI selects for
us. And since I was using the generic PRP0001 thing for the clock device
to probe using the 'compatible' string it's actually even less reliable
and unique...
And btw there's already a precedent for using global names, it's what the
Skylake driver does for the mclk and ssp clocks. To the best of my knowledge
the device specific namespacing does not exist on any ACPI platform. We have
No machine description at all exists on board file systems other than
what we write in C and they manage to cope with this, I'm sure we can
find a way to do it with ACPI. I mentioned clkdev before, that is
something that's done entirely at the Linux level.
a request from Dialog to implement the same thing for SOF to solve
dependencies on the clock being stable before turning on the codec, so if
global names are not acceptable we have a real problem.
If existing usages that have ended up getting merged are going to be
used to push for additional adoption then that's not encouraging.
I wasn't trying to push this against your will, rather I wanted to
highlight that we should be clear on the direction for all these uses of
the clk API in an ACPI context. If what I suggested here is not the
right path, then how do we deal with all the existing cases? This
PCM512x use is not a mainstream usage, we use this board mainly for
validation and for community support, the other cases with 'mclk' and
'sspX_fsync' are critical and impact devices shipping in large volumes.
