[PATCH v1 1/2] ASoC: simple-card: Support custom DAI system clock IDs

[Aidan MacDonald]

Mark Brown <broonie at kernel.org> writes:

> On Wed, Oct 26, 2022 at 03:42:31PM +0100, Aidan MacDonald wrote:
>> Mark Brown <broonie at kernel.org> 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