On 25/10/2022 05:14, Aidan MacDonald wrote:
Krzysztof
Device trees already use standardized enumerations in other areas so it isn't a new idea. Look under include/dt-bindings/clock. Every header there contains an arbitrary enumeration of a device's clocks. In fact most of include/dt-bindings is exactly for this purpose, to define standard values that are not "just numbers" but an enum, a flag, etc, with a special meaning. It is not specific to clocks.
There is no dt-binding for system clock ID, because prior to this patch they were not exposed to DT in any way. But the enumerations themselves already exist, eg. the IDs for nau8821 codec:
/* System Clock Source */ enum { NAU8821_CLK_DIS, NAU8821_CLK_MCLK, NAU8821_CLK_INTERNAL, NAU8821_CLK_FLL_MCLK, NAU8821_CLK_FLL_BLK, NAU8821_CLK_FLL_FS, };
OK, this looks good.
We would just be moving these into dt-bindings if somebody wants to use a codec with simple-card. Future drivers would add the enum into dt-bindings from the start because that's where it belongs.
And the remaining piece I don't get is that these are not bindings for codec, but for sound audio card. You want to set "system-clock-id" property for audio card, while putting clock from codec, which will be used to pass back to the codec... so it is a property of the codec, not of the audio card. IOW, NAU8821_CLK_* does not configure here the clock of the system, but only, only clock of the codec.
Best regards, Krzysztof