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;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <YmN11qt/PqogYruQ@ripper>
References: <20220422230013.1332993-1-bjorn.andersson@linaro.org> <20220423014824.912ACC385A0@smtp.kernel.org> <YmNsYSxLtwLpw98t@ripper> <20220423031350.01299C385A0@smtp.kernel.org> <YmN11qt/PqogYruQ@ripper>
Subject: Re: [PATCH v2 1/2] dt-bindings: clock: Add Qualcomm SC8280XP GCC bindings
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Rob Herring <robh+dt@kernel.org>,
        linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        quic_tdas@quicinc.com
To:     Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Mon, 25 Apr 2022 15:34:24 -0700
User-Agent: alot/0.10
Message-Id: <20220425223426.BE973C385A4@smtp.kernel.org>
Precedence: bulk

Quoting Bjorn Andersson (2022-04-22 20:43:18)
> On Fri 22 Apr 20:13 PDT 2022, Stephen Boyd wrote:
> >=20
> > I'd really rather not have clock-names at all because we spend a bunch
> > of time comparing strings with them when we could just as easily use
> > a number.
>=20
> I know that you would like to get rid of the clock-names for the clock
> controllers. I've looked at it since and while it will be faster to
> execute I still feel that it's going to be harder to write and maintain.
>=20
> E.g. look at gcc_pcie_4_pipe_clk_src, its parents today are
> pcie_4_pipe_clk and bi_tcxo. Something I can reason about being correct
> or not.
>=20
> If we ditch the clock-names I will have:
>=20
> static const struct clk_parent_data gcc_parent_data_14[] =3D {
>         { .index =3D 30 },
>         { .index =3D 0 },

Those numbers could have some #define.

	{ .index =3D PCIE_4_PIPE_CLK_DT }
	{ .index =3D BI_TCXO_DT }

> };
>=20
> Generally we would perhaps use some compile time constant, but that
> won't work here because we're talking about the index in the clocks
> array in the yaml.
>=20
>=20
> But perhaps I'm missing something that would make this manageable?

I dunno. Maybe a macro in the dt-binding header could be used to specify
the 'clocks' property of the DT node that is providing the other side?
The idea is to make a bunch of macros that insert the arguments of the
macro in the right place for the clocks property and then define the
order of arguments otherwise. It would be similar to how
CREATE_TRACE_POINTS is used in include/trace/define_trace.h=20

In the dt-bindings/qcom,gcc-soc.h file:

	#ifdef IN_DTSI

	#undef GCC_DT_NODE_CLOCKS
	#define GCC_DT_NODE_CLOCKS
		clocks =3D <BI_TCXO_DT>,
			 <SLEEP_CLK_DT>;

	#endif /* IN_DTSI */

	#define BI_TCXO_DT 0
	#define SLEEP_CLK_DT 1


And then in the SoC.dtsi file have

	#define IN_DTSI
	#include <dt-bindings/qcom,gcc-soc.h>

	#define BI_TCXO_DT	&xo_board
	#define SLEEP_CLK_DT	&sleep_clk

	...

	clock-controller@a000000 {
		compatible =3D "qcom,gcc-soc";
		reg =3D <0xa000000 0x10000>;
		GCC_DT_NODE_CLOCKS
	};


and then in drivers/clk/qcom/gcc-soc.c file:

	#include <dt-bindings/qcom,gcc-soc.h>

	static const struct clk_parent_data gcc_parent_data_14[] =3D {
		{ .index =3D PCIE_4_PIPE_CLK_DT },
		{ .index =3D BI_TCXO_DT },
	};

The benefit I see to this is that the index for each clock is in the
header file (BI_TCXO_DT is 0) and it's next to the clocks property.
Someone could still mess up the index based on where the macro is used
in the clocks property though.