[RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock

[Pierre-Louis Bossart]

>> 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.