Mark Brown <broonie@xxxxxxxxxx> writes: > On Wed, Oct 26, 2022 at 03:42:31PM +0100, Aidan MacDonald wrote: >> Mark Brown <broonie@xxxxxxxxxx> writes: >> >>> There is a strong case for saying that all the clocking in CODECs might >>> fit into the clock API, especially given the whole DT thing. >>> >> The ASoC APIs don't speak "struct clk", which seems (to me) like a >> prerequisite before we can think about doing anything with clocks. > > Right, they probably should. Let me throw out an idea then... the clock API will probably need to gain the ability to express constraints, eg. limit a clock to set of frequencies or frequency ranges; ratio constraints to ensure a set of clocks are in one of a specified set of ratios; and maybe require that certain clocks be synchronous. This'd go a long way toward making the clock API suitable for audio clocking. >> Even if ASoC began to use the clock API for codec clocking, it's not >> clear how you maintain backward compatibility with the existing >> simple-card bindings. You'd have to go over all DAIs and mimic the >> effects of "snd_soc_dai_set_sysclk(dai, 0, freq, dir)" because there >> could be a device tree relying on it somewhere. > > Of course, you'd need to define bindings for devices with multiple > clocks such that things continue to work out compatibly. > >> So... given you're already stuck maintaining .set_sysclk() behavior >> forever, is there much harm in exposing the sysclock ID to the DT? > > Yes, it's ABI and the more baked in this stuff gets the more issues we > have when trying to integrate with the wider clock tree in the system - > for example when devices are able to output their system clock to be > used as a master clock for a device which can use the clock API as an > input. It's fine in kernel but we should be trying to keep it out of > ABI. Fair enough. It's too bad this limits the usefulness of simple-card, but for the time being I'm happy maintaining these patches out of tree. Regards, Aidan
