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.
Attachment:
signature.asc
Description: PGP signature
