On Wed, Apr 15, 2020 at 09:44:12AM -0500, Pierre-Louis Bossart wrote:
> On 4/15/20 6:36 AM, Mark Brown wrote:

> > Architectures that don't have firmware bindings use straight C code to
> > register and set things up.  Machine drivers are essentially board
> > files, they're just audio specific bits of board file that use audio
> > APIs and so are in the sound directory.

> Humm, we may have a conceptual disconnect here. In the ACPI world, there is
> no support for the machine driver - unlike Device Tree. It is probed when

This is nothing to do with device tree except in that it has useful
firmware descriptions of the hardware.

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

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

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