[PATCH 1/1] dt-bindings: clock: meson: Convert axg-audio-clkc to YAML format

Jerome Brunet jbrunet at baylibre.com
Thu Aug 10 00:32:09 PDT 2023


On Thu 10 Aug 2023 at 08:11, Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 09/08/2023 20:44, Alexander Stein wrote:
>> Hi,
>> 
>> Am Mittwoch, 9. August 2023, 15:02:23 CEST schrieb Krzysztof Kozlowski:
>>> On 09/08/2023 08:58, Jerome Brunet wrote:
>>>>>> +      required:
>>>>>> +        - '#reset-cells'
>>>>>
>>>>> else:
>>>>>   properties:
>>>>>     '#reset-cells': false
>>>>> ???
>>>>>
>>>>>
>>>>> You need to constrain the clocks per variant. Probably names are also
>>>>> specific to each one, so the list of names can be moved here and you
>>>>> keep just min/maxItems in the top level property.
>>>>>
>>>>
>>>> input clock names and constraints are the same for all 3 variants.
>>>
>>> Then why do you have this huge, apparently unnecessary, oneOf? If it's
>>> the same, then drop the oneOf and make number of clocks fixed.
>> 
>> But as far as I understand the number of clocks is not fixed. As Jerome pointed 
>> out in the other post, it can have any combination of clocks and range from 1 
>> up to 11, where 'pclk' is always 1st clock.
>> I currently have no idea how to constraint that, despite limiting the number 
>> of clock-names.
>
> The same as in all other clock controllers (was also present on my list
> of useful patterns - Variable length arrays (per variant)):
> https://elixir.bootlin.com/linux/v5.19-rc6/source/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml#L57

In the example provided, the number and list of clocks required by each
controller variant is fixed, if I'm reading it correctly

Here the controller (regardless of the variant) accepts a maximum 29
clock inputs. Only pclk is required. It is valid to have any of 28
optional clocks at index 2, 3, etc ...

I guess the question is how do you recommend to model that ?
I can think of 'Anyof' with all the optional clocks repeated 28 times
but that would be fairly ugly.

>
> Best regards,
> Krzysztof




More information about the linux-amlogic mailing list