Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d47d0ceb834ca56a4733e226e89a4f2b.sboyd@kernel.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <e8ee511863ce2aa9b09b7f0c4fa9b6919603c8f0.camel@maquefel.me>
References: <20230424123522.18302-1-nikita.shubin@maquefel.me> <20230424123522.18302-13-nikita.shubin@maquefel.me> <d15b580f84ac89274cde3785168b0e26.sboyd@kernel.org> <e8ee511863ce2aa9b09b7f0c4fa9b6919603c8f0.camel@maquefel.me>
Subject: Re: [PATCH 12/43] clk: ep93xx: add DT support for Cirrus EP93xx
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Arnd Bergmann <arnd@kernel.org>, Linus Walleij <linusw@kernel.org>,
        Alexander Sverdlin <alexander.sverdlin@gmail.com>,
        Michael Turquette <mturquette@baylibre.com>,
        linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
To:     Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Tue, 13 Jun 2023 13:44:49 -0700
User-Agent: alot/0.10
Precedence: bulk

Quoting Nikita Shubin (2023-05-15 06:31:41)
> Hello Stephen!
>=20
> Thank you for your review.
>=20
> Acknowledged all remarks, however, i didn't fully understood some of
> the requirements:

When the reply is taken out of context it is harder for me to recall
what we're talking about.

>=20
> > And maybe this can be registered from wherever the regmap is created?
>=20
> Are you suggesting that all clock from init, i.e. "pll1", "pll2",
> "hclk", "fclk", "pclk"
>=20
> Should be moved to=C2=A0SoC driver instead:
>=20
> https://lore.kernel.org/all/20230424123522.18302-3-nikita.shubin@maquefel=
.me/
>=20
> ?

Sure? That looks like a possibility.

>=20
> > Does some interrupt or timer driver use dma? Why are these registered
> > early?
>=20
> ep93xx_dma uses subsys_initcall(ep93xx_dma_module_init)
>=20
> https://elixir.bootlin.com/linux/v6.3.2/source/drivers/dma/ep93xx_dma.c#L=
1430
>=20
> I can move clk to using arch_initcall and move all stuff to probe, i
> think...

Sounds like the answer to my question is no. In which case moving to
arch_initcall() or probe will work. Please try.

>=20
> > Why is this in arm/ directory? Isn't it a clock controller?
>=20
> ep93xx clocks, reboot, pinctrl use syscon regmap and some special
> functions from SoC, i.e. "Syscon Software Lock Register" - so we are
> able to write to some registers only after writing some magik value
> there.
>=20
> So all above use regmap from SoC.

There can be an API in a header located in include/soc/ that implements
the magik value unlock sequence?

>=20
> Should make a separate clock controller like one i did for pinctrl ?
> Then it should look like:
>=20
> syscon@80930000 {
>   compatible =3D "cirrus,ep9301-syscon",
>                "syscon", "simple-mfd";
>   reg =3D <0x80930000 0x1000>;
>   #reset-cells =3D <1>;
>      =20
>   clocks {
>     xtali: oscillator {
>       compatible =3D "fixed-clock";
>       #clock-cells =3D <0>;
>       clock-frequency =3D <14745600>;
>     };
>   };
>      =20
>   clock-controller {
>     #clock-cells =3D <1>;
>     compatible =3D "cirrus,ep9301-clk";
>     clocks =3D <&xtali>;
>   };
> };
>=20
> Or even simply:
>=20
> clocks {
>   xtali: oscillator {
>     compatible =3D "fixed-clock";
>     #clock-cells =3D <0>;
>     clock-frequency =3D <14745600>;
>   };
> };
>      =20
> clock-controller {
>   #clock-cells =3D <1>;
>   compatible =3D "cirrus,ep9301-clk";
>   clocks =3D <&xtali>;
> };

The DT binding shouldn't be making sub-nodes to match driver structure
of the kernel. Instead, there should be a node for a register range that
represents a device on the bus. That device may be multipurpose, in
which case it can probe as a platform driver and that platform driver
can create some number of auxiliary bus devices for the sub
functionality of the device. We shouldn't be prescribing Linux software
constructs onto the DT binding.