From: Jerome Brunet <jbrunet@baylibre.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Alexander Stein <alexander.stein@mailbox.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Dmitry Rokosov <ddrokosov@sberdevices.ru>
Cc: linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/1] dt-bindings: clock: meson: Convert axg-audio-clkc to YAML format
Date: Thu, 10 Aug 2023 09:51:05 +0200 [thread overview]
Message-ID: <1jsf8r9v1v.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <d2225b8a-a622-3936-1e43-d5a9801c2cd7@linaro.org>
On Thu 10 Aug 2023 at 09:46, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 10/08/2023 09:32, Jerome Brunet wrote:
>>>>> 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 actually doubt that it is optional. These are valid clock inputs. I
> could imagine they are optional depending on the use-case, like some
> block being turned off or on... but then still the clock is there, just
> not actively used.
>
> Aren't you now describing existing Linux driver?
They are valid inputs but not required. It is valid (and expected) to
have a fair share of them not connected. The slave clocks just don't exist
most of the time, and the IP can totally accept unwired master clock
inputs on SoC variant. Nothing is going to break down if some are
missing.
From the controller perspective, the description given here is correct
and the inputs are optional.
The more generic question is how do we deal with multiple,
independent and optional ressources ? Because then, the order in which
they appear cannot be predicted.
>
>> 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
next prev parent reply other threads:[~2023-08-10 8:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 19:48 [PATCH 1/1] dt-bindings: clock: meson: Convert axg-audio-clkc to YAML format Alexander Stein
2023-08-09 6:15 ` Jerome Brunet
2023-08-09 18:37 ` Alexander Stein
2023-08-09 6:38 ` Krzysztof Kozlowski
2023-08-09 6:58 ` Jerome Brunet
2023-08-09 13:02 ` Krzysztof Kozlowski
2023-08-09 13:46 ` Jerome Brunet
2023-08-09 14:23 ` Krzysztof Kozlowski
2023-08-09 18:44 ` Alexander Stein
2023-08-10 6:11 ` Krzysztof Kozlowski
2023-08-10 7:32 ` Jerome Brunet
2023-08-10 7:46 ` Krzysztof Kozlowski
2023-08-10 7:51 ` Jerome Brunet [this message]
2023-08-21 17:01 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1jsf8r9v1v.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=alexander.stein@mailbox.org \
--cc=conor+dt@kernel.org \
--cc=ddrokosov@sberdevices.ru \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox