On Wed, Apr 15, 2020 at 03:22:50PM -0500, Pierre-Louis Bossart wrote:
In the case of this driver could you look at registering the link from the device for the clocks? Have it say "I supply SCK on device X" as it registers. That should be fairly straightforward I think, we do that for one of the regulators.
When you wrote 'in the case of this driver', were you referring to the clock provider, saying 'I support SCK on device i2c-104C5122:00' ?
Yes.
If you have a pointer on the regulator example, I'd appreciate it, I am really way beyond my comfort zone.
The arizona driver is what I was thinking of, that's more complex than you proabably need as it's a MFD.
Maybe an alternate suggestion if you want to avoid hard-coded strings in the kernel: what if we added optional properties for the clock lookup name in both the codec and clock driver, and set the name in a _DSD blob. That would move the platform-specific names to platform firmware, and avoid the links described above that are probably ACPI-only.
If you read the lookup information from firmware somehow that's probably fine I think. It's not nice but if it's baked into firmware...
I think by now there's ample evidence that it's worth investing in better firmware descriptions :(
Indeed, and tools to check they are correct! Most of the stuff we defined for SoundWire ends-up wrong or undefined, still an uphill battle...
The audio-graph-card appears to be working really well FWIW, Morimoto-san did an excellent job there.