From: Jerome Brunet <jbrunet@baylibre.com>
To: Alexander Stein <alexander.stein@mailbox.org>,
Rob Herring <robh+dt@kernel.org>,
Neil Armstrong <narmstrong@baylibre.com>,
Kevin Hilman <khilman@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: devicetree@vger.kernel.org, linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 1/1] arm64: dts: meson-g12b-odroid-n2: move assigned-clocks
Date: Tue, 21 Dec 2021 11:54:07 +0100 [thread overview]
Message-ID: <1j4k7287bv.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <4534376.LvFx2qVVIh@kongar>
On Sun 19 Dec 2021 at 10:56, Alexander Stein <alexander.stein@mailbox.org> wrote:
> Am Samstag, 18. Dezember 2021, 16:03:16 CET schrieb Jerome Brunet:
>>
>> On Sat 18 Dec 2021 at 15:26, Alexander Stein <alexander.stein@mailbox.org> wrote:
>>
>> > dtschema expects a 'clocks' property if 'assigned-clocks' is used, but
>> > 'sound' node does not.
>> > So move the MPLL[0-2] clock settings &clkc_audio which actually use them.
>>
>> No, this does not make sense.
>> The sound card needs the clocks set in such way - nothing else
>> The clock controller work just as well regarless of the clock rate
>>
>> Having a clock property or not does not change that
Also the documentation of assigned does not mandate that.
>
> Well, I checked what others did to fix this warning. So I did the same as in [1].
> Despite that, IMHO if you split 'assigned-clocks' for the same clock ´all
> over users who is gonna win?
1. This is explicitly forbidden by the assigned-clock binding documentation
2. Like other interfaces, it is likely a last write wins
The fact the ID assigned by the card and the one claimed controller are
the same is merely a coincidence. The ID assigned could very well have
been internal to the audio controller.
> Because the sound card needs the clocks set
> his way it is set, it is done in the same file.
If I push this logic further, I may as well put everything at root of DT,
or anywhere else, as long as it is in the same file and there is a clock
property for the schema. We could put it with uart, that would work ;)
(just kidding)
The cards needs these rate because of rate family we choose to support,
and how we choose to support them. This is where the assignment makes
sense.
>
> Best regards,
> Alexander
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4afb06afd76855932a2d19c983c013105f1cfb9a
>
>> > This fixes the dtschema warning:
>> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
>> >
>>
>> Then the schema needs fixing IMO
>>
>> > Signed-off-by: Alexander Stein <alexander.stein@mailbox.org>
>> > ---
>> > .../boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 15 +++++++--------
>> > 1 file changed, 7 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
>> > index 9c05c83453f5..85257507206c 100644
>> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
>> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
>> > @@ -252,14 +252,6 @@ sound {
>> > "U19 INR", "ACODEC LORP",
>> > "Lineout", "U19 OUTL",
>> > "Lineout", "U19 OUTR";
>> > -
>> > - assigned-clocks = <&clkc CLKID_MPLL2>,
>> > - <&clkc CLKID_MPLL0>,
>> > - <&clkc CLKID_MPLL1>;
>> > - assigned-clock-parents = <0>, <0>, <0>;
>> > - assigned-clock-rates = <294912000>,
>> > - <270950400>,
>> > - <393216000>;
>> > status = "okay";
>> >
>> > dai-link-0 {
>> > @@ -365,6 +357,13 @@ &cecb_AO {
>> > };
>> >
>> > &clkc_audio {
>> > + assigned-clocks = <&clkc CLKID_MPLL2>,
>> > + <&clkc CLKID_MPLL0>,
>> > + <&clkc CLKID_MPLL1>;
>> > + assigned-clock-parents = <0>, <0>, <0>;
>> > + assigned-clock-rates = <294912000>,
>> > + <270950400>,
>> > + <393216000>;
>> > status = "okay";
>> > };
>>
>>
prev parent reply other threads:[~2021-12-21 12:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-18 14:26 [PATCH 1/1] arm64: dts: meson-g12b-odroid-n2: move assigned-clocks Alexander Stein
2021-12-18 15:03 ` Jerome Brunet
2021-12-19 9:56 ` Alexander Stein
2021-12-21 10:54 ` Jerome Brunet [this message]
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=1j4k7287bv.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=alexander.stein@mailbox.org \
--cc=devicetree@vger.kernel.org \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=narmstrong@baylibre.com \
--cc=robh+dt@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